[dns-operations] DoS with amplification: yet another funny Unix script

[Klaus Darilion]

Hi Paul!

On 10.09.2012 19:48, Paul Vixie wrote:
> please don't do, or promulgate, this. ddos filtering in order to do more
> good than harm has to be based on the attack's answer, not on its query.
> see also the three flaws identified above, which also apply here. (so,
> your approach has four, adding one.)
>
> vernon schryver and i explain this in the technical note at
> <http://www.redbarn.org/dns/ratelimits/>.

I just read your technical note and have some questions/comments:

- filter based on response vs. request

Is it correct that filtering based on responses is better only for 
NXDOMAIN responses or error responses. If the forged requests are 
requests for valid domain names, then analyzing the request should be 
fine too.

- filtering in the name server vs. external filtering

Of course it is easiest to track the states in the name server, but I do 
also see advantages in doing the filtering in an external node (upstream 
firewall, local iptables). For example I do not have to worry about the 
used name server software and I can use the same rules for bind, 
powerdns, nsd ... backends. I also suspect that filtering in kernel 
space may be faster. As a personal preference I try to separate 
functionality into dedicated nodes.

- DNS RRL Responder Behavior

The tuple <mask(IP), imputed(NAME), errorstatus> is used to select a 
state blob. In the amplification attacks on our authoritative servers we 
see only valid requests without duplication, e.g.:
ANY domain1.com
ANY domain2.com
ANY domain3.com
ANY domain4.com
ANY domain5.com

Thus, it may take some time until the attacker starts with domain1.com 
again. If I understand the Responder Behavior correct, this would mean 
that filtering is never triggered if a domain is not queried 
RESPONSES-PER-SECOND times per second. Or do I miss something here?

Thanks
Klaus