> So it seems that DNS querys can use TCP. BUT what we need is the > server > FORCING the use of TCP. It *seems* we could force this by editing > the > file "/etc/services" and commenting or deleting the UDP entry: > > whois 43/tcp nicname # usually to > sri-nic > domain 53/tcp > > #domain 53/udp > mtp 57/tcp # deprecated > > This way, both the *local* name server and *local* resolver would > use > TCP on its domain name related tasks... This means that *local* > querys > would work over TCP. That will do nothing. The "/etc/services" is just used to pretty up some displays as far as DNS is concerned. Remove the entry will do nothing. > The problem comes up, when an standard remote client querys a > 'TCP-forced' system. What happens when such a client starts an UDP > query to a TCP service? Is it able to detect it and restart the > process > using TCP? Nothing will happen. The query will fail. > Unfortunately, I could not found any kind of information on this > matter. > It seems to me that this is an unspecified case. It seems that UDP > & TCP > are treated as separete worlds... I think that, in the best case, > this > will depend on vendor implementation, and not as an standard > behaviour. Every implementation I've ever seen will assume that a server that doesn't respond to UDP queries is dead. Even zone transfers, which do use TCP, are almost always preceded by an essential UDP fetch of the zone serial number to decide that the transfer is necessary. > Besides that, we have de UDP/TCP interoperation problem mentioned > before. This would imply reconfiguring or patching all the DNS > servers > *and clients* in the world, among other things... So it 'seems' > that it > is not practical approach. ;P No client changes are required. Clients can still use UDP to query their own name servers. Name servers would have to force TCP on queries from remote name servers. > Perhaps, It may be interesting a review or a new generation of the > standard. I, honestly, ignore if this it's being done. Anyway, > given > what we have today it's *the* long term solution, isn't it? ;P. A better solution is a quick UDP 'handshake' before a remote server or client is authorized to use a name server. Thus, if you wish to use a name server, you'd send a UDP 'connection request' packet to it and it would reply with a key that you could use for future requests. Since the key would be sent to the victim, and you couldn't amplify without it, the attack would be gone. The problem is, over the Internet at large, name servers need to connect to large numbers of different name servers, as opposed to the same ones over and over. So this would have some impact. The important thing to realize is that the first step to fixing this is name servers not providing server-client service to anyone. Once the server-client service is restricted to 'local' IPs, the server-server protocol can be locked down. DS
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:56:01 PDT