[dns-operations] rate-limiting state

Colm MacCárthaigh colm at stdlib.net
Fri Feb 7 17:02:46 UTC 2014


On Fri, Feb 7, 2014 at 6:16 AM, Tony Finch <dot at dotat.at> wrote:

> What not just the victim? In the absence of RRL the DDoS attack is likely
> to cause collateral damage, yes. In the presence of RRL non-victims are
> unaffected as long as the attack isn't overwhelming the name server.
>

Both can cause collateral damage, but to different targets. RRL does reduce
the collateral damage to a reflection target. But it also increases the
collateral damage to your legitimate users. If an attacker spoofs a popular
resolver, then for just 5-10 queries per second they cause a degradation in
service to the real legitimate users of that resolver. With the default
settings, 12.5% of queries from that resolver may not get any answer at
all, even with three attempts, and the lookup time is increased by about
1.3 RTTs on average.  With the resolver trying 3 authoritative nameservers,
the availability hit diminishes to about 0.2% (which brings us to two
nines), but the RTT hit gets worse.

Now if I have a botnet or client that can generate 1M PPS (this is small,
but adjust to any number), I can try to spoof 66,666 popular resolvers
(this is a knowable set) at 5 QPS each to 3 auth servers, I can use RRL to
degrade service in a more widespread way.

Now, let's say you have the capacity to answer these queries (which is
realistic for some) which behavior is better for your users? Just answering
the responses? Or rate-limiting the responses?

My overall point is that with RRL there is some trade-off between
protecting innocent reflection victims and opening yourself to an attack
that degrade service to your real users in some way. Were RRL to be widely
deployed, attacks could shift to table-exhaustion and popular-resolver
spoofing and be effective in different ways.

-- 
Colm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140207/e91b34c4/attachment.html>


More information about the dns-operations mailing list