[dns-operations] rate-limiting state
vjs at rhyolite.com
Fri Feb 7 20:22:59 UTC 2014
> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm at stdlib.net>
> 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.
Great! Colm has finally read a little. He still hasn't bothered
> 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.
- there are a lot more than 66K open resolvers, almost all of
which should be closed, but there are not 66K popular resolvers
in the sense that Google, OpenDNS, Comcast, &co are popular.
- My (or someone else's) 12.5% number copied above assumes only
a few retries. Colm's latest doomsday scenario would cause
more than only a few retries, which would drive that 12.5% way
down. The neat thing about the probabililty of failure in
schemes like this is that it goes as (a/b)**r where a<b and r
is the number of retries.
- Colm still hasn't paid attention to that extra "R" in "RRR" and is
still assuming that RRL is about simplistic IP source address
rate limiting. His botnet would need to forge not only IP source
addresses but also the (qclass,qtype,qname) tuples of his victims.
> 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.
That is always true about any defense. The resources including
bandwidth, CPU cycles, and human sweat devoted to RRL necessarily
reduce what can be spent for the service itself. RRL has a remarkably
light footprint as such things go, but while Colm's specific
complaints are trolling nonsense, RRL's footprint is non-zero. RRL
should not be used in networks that do not DNS reflection issues.
> Were RRL to be widely
> deployed, attacks could shift to table-exhaustion and popular-resolver
> spoofing and be effective in different ways.
RRL is long since widely deployed, the bad guys still haven't switched
in that way.
That bit about "table exhaustion" is trolling based on the false
assumption that RRL is a naive firewall rate limit that uses a naive
firewall ACL (naive in this context but not necessarily other
There is an serious, ultimately fatal problem with RRL that has been
discussed repeatedly here and elsewhere, but it's unrelated to Colm's
Vernon Schryver vjs at rhyolite.com
More information about the dns-operations