Re: Possible Denial Of Service using DNS

[davids () WEBMASTER COM (David Schwartz)]

>    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