query dropping vs. returning nxdomain
Geert Jan de Groot
GeertJan.deGroot at xs4all.nl
Tue Mar 7 16:12:03 UTC 2006
On Tue, 07 Mar 2006 15:06:53 +0000 paul at vix.com wrote:
> # > Would it generally be considered poor form to drop queries you do
> # > not want to answer? Perhaps not only queries that would return
> # > NXDOMAIN, but also queries that maybe administratively you do not
> # > wish to answer.
> # I don't look forward to debugging a world where queries are
> # just dropped. There is too much of that with EDNS queries
> # to DNS servers.
> and yet, that's how it's got to be. as i trace and study DDoS attacks
> involving spoofed-source packets from bots toward reflectors and then
> responses from reflectors toward actual victims, i find that even if
> the reflector does not amplify (for example, sends back SERVFAIL or an
> ICMP rather than a 4X TXT EDNS answer), it's still a very painful attack
> and it's still pretty much impossible to trace.
In contrast to the phone-network that just gives a busy tone,
the Internet comes with it's built-in debugging tools:
ping, traceroute, nslookup (nee host or dig).
We all use these debugging tools every day.
At the same time *&^&*( filter these packets, making the Internet
ever-ever-harder to run. Randy Bush made a pretty good statement on this,
see http://www.nanog.org/mtg-0210/ppt/bushcomplex.pdf, especially slide 13.
It is a lot simpler to make these reflectors by sending SYN packets
to closed ports, except that most operating systems rate-limit
the resulting RST-responses.
I think that a similar mechanism might work in this case too,
reducing the maximal packet rate for these packets,
but keeping the debugging capability in.
This doesn't forego the problems of a DDoS attack, but makes them
a lot less, as one now needs a much bigger set of reflectors
to create a certain amount of bandwith for packet flooding.
While I don't have a good answer, I don't think that cripping
an application is the answer to DDoS attacks.
Secondly, I think that the vast majority of nameservers don't have
a high packet rate and hence would continue to work with these
rate-limiters in place by default. Having them in by default would mean
that 95% of the world can run this protection by default,
w/o any configuration.
The ones that have a higher load that would trigger the rate-limiter
are hopefully ran by propellorheads with clue, and at least they would
need clue to change the rate limiter.
More information about the bind-workers