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.

Makes sense?

Geert Jan



More information about the bind-workers mailing list