[dns-operations] DNS ANY record queries - Reflection Attacks
vjs at rhyolite.com
Tue Sep 11 23:28:08 UTC 2012
> From: Eric Osterweil <eosterweil at verisign.com>
> Fair enough, except I'm pretty sure some of the deployment being
> talked about (even in this thread) is at the authority (not the
> > Paul Vixie and I are not advocating DNS rate limiting in firewalls.
> > We're talking about rate limiting in the hosts at the ends of the
> > intertubes.
> Again, this thread started somewhere else. Clearly, I agree that
> people should be able to manage their own user experiences. ;)
By definition, all DNS servers and clients run on hosts. When a
router or bridge does DNS stuff, it is a host and subject to the
Host Requirements RFCs. I and I think some others have been talking
about filtering DNS requests and/or responses in the following hosts
and/or firewalls close to those aforesaid hosts:
- DNS servers, either authority servers or resolvers
- putative DNS clients that are targets of DNS reflection DoS attacks.
The money-back warranty on the BIND RRL patch only covers its installation
on authority DNS servers, although I have received positive reports
from resolver operators. The current version includes additional
features suggested by operators of combined authorities/resolvers.
> 1 - If you uniformly drop 50% of a 100x amplification attack, you
> are still reflecting 50x amplification, right?
That is wrong for the BIND RRL patch. With default parameters, the
BIND RRL drops 50% of responses and substitutes a small TC=1 response
for the other 50%. That gives an amplification for the responses it
sends of <= 1.0 responses sent and an overall amplification <= 0.5.
(It currently forgets about ENDS in the TC=1 responses giving a default
amplification of < 0.5. An influential commentator calls that a bug.)
> 2 - If you wait for (say) 4 responses, your stub (the client
> driving the upstream resolver) has almost certainly timed out, and
> the DDoS has succeeded, if I'm not mistaken, right?
I think that is mistaken. Consider the implications of the default
values of "attempts" and "timeout" keywords in /etc/resolv.conf and
of _res.retry and _res.retrans the libc interface to the de facto
> Then it should be easy enough for someone to explain the above, no?
> Having deployed something does not mean that it was effective, and
> blocking traffic does not tell me how much legit traffic and how much
> attack traffic was blocked. I don't see why this is so hard, I just
> want to understand the assertion.
Consider where the BIND RRL patch has been installed and then ask
yourself why *you* have not noticed any collateral response losses.
Vernon Schryver vjs at rhyolite.com
More information about the dns-operations