[dns-operations] DNS deluge for x.p.ctrc.cc

Geo. geoincidents at nls.net
Mon Mar 6 13:41:01 UTC 2006


> and yet, the time has come when the default out-of-box configuration for
> smtp relays is to non-open.

Yes and that affects smtp and only smtp and the problem was with smtp not a
spoofing issue. Blocking or even rate limiting DNS will affect far more than
just DNS and will manifest itself as problems with every other function run
over the network.

> if root and tld servers accept packets from recursive name servers known
to be
> open and known to have been used as amplifiers in prior attacks, then they
> will not be available during amplifier attacks, but they will be available
to
> the entire internet.  that's the status quo, and it's a possible choice of
> "most responsible way to operate".
>
> if root and tld servers drop packets from recursive name servers  known to
be
> open and known to have been used as amplifiers in prior attacks, then they
> will not be available to the entire internet, but they will be available
> during attacks.  that's the prospective change, and it's a possible choice
> of "most responsible way to operate".

Those are not the only two possible choices. There is another although I'm
not versed in dns enough to know how good a solution it would be. Use TCP
instead of UDP, this would address the issue of spoofing dns requests and
remove the attack vector. Allow UDP from local clients but restrict
anonymous remote clients to TCP as the protocol for querying an open
recursive dns server. UDP is easy to spoof because it's connectionless, TCP
isn't.

I'm not a programmer but don't mail servers already fall back to tcp if a
query response is too long for UDP? Is that just mail servers that do this
or is this a general function of all software that does dns queries? I
dunno, but I think it's certainly as much of an option as locking down every
dns server on the planet.

Geo.




More information about the dns-operations mailing list