[dns-operations] DNS ANY record queries - Reflection Attacks

[Vernon Schryver]

> 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
> resolver)...  

> > 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
standard stub.



> 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.
See https://lists.dns-oarc.net/pipermail/dns-operations/2012-June/008453.html


Vernon Schryver    vjs at rhyolite.com