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

[Vernon Schryver]

> From: Andrew Sullivan <ajs at anvilwalrusden.com>

> > Perhaps I misunderstand, but I think that's wrong in general and based
> > on the persistent and by now very irritating confusion between client
> > rate limiting and response rate limiting (RRL).  
>
> No, it isn't.

Yes, it is.  Please pause to understand the difference between
response rate limiting and client rate limiting or DoS defenses.

> Suppose that DNSprov provides DNS service on behalf of HiProfile.

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

That is where Andrew Sullivan goes wrong in confounding client rate
limiting at DNSprov with response rate limiting at DNSprov or DoS
defenses at MrISP.

MrISP's resolver should not be asking about HiProfile's RRs more often
than once per TTL.  Since TTLs are always more than 1 second (to
understate the common case by a factor of 100X or 1000X), MrISP's
resolver will only barely affected by RRL provided it gets a response
now and then.  Of course, there are some caveats:

   - if MrISP's resolver is a farm hiding behind a single NAT or
      load balanced address or CIDR block and there are enough
      resolvers in the farm, "it" might ask often enough to be
      rate limited.

   - MrISP's resolver must get some answers.  With the RRL "slip"
      default of 2 and the typical 3 retries, there is an 87.5%
      probability that MrISP's resolver will get a "slipped" or
      truncated response  from DNSprov despite the flood of requests
      for the A RR for HiProfile forged from MrISP's resolver
      If a user at a browser who gets an "page not working" error
      tries a second time, the odds of MrISP's resolver working
      rise to 98.4%.  For at least minutes and usually hours afterwards,
      MrISP's resolver's cache will deliver A RRs for HiProfile and
      not notice anything amiss.

Note also that without RRL at DNSprov, MrISP's resolver will be flooded
with responses from DNSprov to the forged requests.  The DoS defenses
at MrISP are likely to "scrub" most of the responses from DNSprov
whether to real or forged requests, because the responses are a DoS
attack.  Because of that, MrISP's resolver has less chance of resolving
HiProfile without RRL at DNSprov than with RRL at DNSprov.


Vernon Schryver    vjs at rhyolite.com