[dns-operations] RRL specified in a stable place?

[Paul Vixie]

may i suggest that the ratelimits mailing list is a better place for
this argument. but herewith:

Andrew Sullivan wrote:
> Suppose that DNSprov provides DNS service on behalf of HiProfile.
> Suppose that HiProfile has one of those services that is really
> susceptible to the "no response, kill the page load" problems that the
> big web presences -- Amazon, Yahoo, Twitter, &c -- keep worrying
> about. Moreover, because of the usual commercial reasons such services
> have, the TTLs on HiProfile records are short. Now, suppose that MrISP
> is a very large US-based cable provider with something like (say) 10%
> of the domestic market. All MsAttacker needs do to cause significant
> pain is to send a DoS towards DNSprov with source addresses of MrISP's
> resolver querying for HiProfile's names. RRL will work, of course, in
> the sense that it will stop spewing garbage. But it will also rate
> limit responses to anyone apparently coming from that address. This
> means that MsAttacker can cause MrISP's resolvers to be rate-limited
> as long as MsAttacker can keep up the attack for something longer than
> $TTL on some record for HiProfile.

yes.

> In other words, MsAttacker can cause a short but probably effective
> DoS against HiProfile, and with a little work can probably cause
> intermittent outages for a significant percentage of MrISP's customers
> every few minutes. 

no.

> This is perhaps a less bad attack than before, depending on DNSprov's
> provisioning; but it is contractually devastating for DNSprov, who
> promised not to drop queries on the floor for HiProfile, but who has
> dropped such queries on purpose. One can mitigate this to some extent
> with various additional epicycles to the RRL approach (and I note that
> you've done so, and congratulate you in your acumen and creativity),
> but one cannot solve the fundamental issue, which has to do with very
> high-value targets and very large communities behind certain
> high-value resolvers. It's a trade-off. RRL works well in some --
> maybe most -- cases, but it's not something one can do in others.
> That's hardly surprising, I think. 

wrong.

factually, rrl can't fix everything, but it makes no case worse than it
would otherwise be. i've heard from a lot of experts who said that rrl
creates a new DoS vector, but none of those claims has held up.

in the case you outline, there would already not be (that is, without
RRL) service for HiProfile at MrISP, but due to congestion rather than
RRL's prevention of that congestion.

if anyone wants to blame RRL for not solving all the world's problems,
my shoulders are very broad -- bring it on. but if you want to blame RRL
for creating a new problem -- tell me more.

paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130204/5e78b083/attachment.html>