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

[Vernon Schryver]

> From: Eric Osterweil <eosterweil at verisign.com>

> > That computation might be correct if DNS clients did not retransmit,
> > if the BIND RRL idea involved only discarding responses,
> > and if Paul and I proposed dropping 99% of all traffic for a CIDR block.
> > We advocate none of that.
>
> Hmm.. I may still be missing some nuances, what are the specifics?

Instead of my writing a new complete description or even worse for other
readers, copying-and-pasting the existing documentation,
please see the recently mentioned http://www.redbarn.org/dns/ratelimits
That page has a link to a technical note talking about the problem,
a link to code for serious specifics,
and even a link to draft changes to the BIND9 ARM.


> So, I don't understand something... If you see a lot of identical
> responses from an authority, could that not be because it is an authority
> for those responses?  How do you distinguish a netblock with multiple
> resolvers, or anycast resolvers? 

The BIND RRL code is part of the resolver.  It does not "see a lot of
identical responses from an authority" except when it is the authority.


>                                   Perhaps more directly, are you
> dropping responses from legitimate clients and how do you feel about
> them being collateral damage?

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.


> So, every identical response either gets dropped or gets its TC bit set?

No, every *excessive* identical response is either not sent (dropped)
or a tiny TC=1 response is sent instead.


> > A DNS client that retransmits N times to a DNS server that answers
> > 50% with TC=1 of the time will get an answer to 1-(0.5)^N of its
> > queries.  For N=4, it will get a TC=1 answer 94% of the time.
>
> Wait, I'm very confused... The above sounds like you respond to
> 94% of the reflector attack queries (which furthers the attack).

No, I was pointing out that P(R1&R2&R3&R4)=P(R1)*P(R2)*P(R3)*P(R4)
Given a uniform drop probability of 50%, the probability that all 4
responses to an initial request and its 3 retransmissions will dropped
is 6%.  (Or should that be N=5?--I always seem to be off by 1.
In which case 97% of requests would be answered.)


> Well, if doing something hurts the legitimate clients more than doing
> nothing, I think you need to be upfront about that.  I think that's
> worse than doing nothing.

That's like opposing mechanical spam filtering by pointing to mechanical
false positives while ignoring the higher false positive rate of the
otherwise inevitable purely manual filtering on subjects and senders.
If you do nothing, then legitimate clients will be denied all service
by the firewall rules advocated here or by IP bandwidth rate limits
at the source (DNS servers) and the DoS targets.  Remember why it's
called a DoS.

You are saying that you would rather try to receive 1000 1500 Byte
bogus DNS responses per second along with all your legitimate DNS
responses that don't get dropped from router queues by that flood
instead of 10 bogus responses and useful responses to 94% of your
requests.


> OK, but you've also almost certainly eliminated the legitimate
> client's ability to query you for responses.

That is simply false.  When Paul Vixie wrote that the BIND RRL code
is effective, he wasn't talking about theory or small scale tests.  It
has been in use on some major DNS servers for months.  If there were
enough collateral damage to talk about, someone would have complained.


Vernon Schryver    vjs at rhyolite.com