[ratelimits] rate limiting options for large recursors

[Vernon Schryver]

> From: William Taylor <williamt at corp.sonic.net>

> I was wondering if anyone could recommend some starting rate-limit options
> for large recursors. Any insight would be most appreciated.
>
> Right now to test with I have this:
>
>         rate-limit {
>                 responses-per-second 100;
>                 window 5;
>                 ipv4-prefix-length 32;
>                 log-only yes;
>         };

Generalizations or rules of thumb are likely to be inaccurate, as with
many abuse defenses.  But since you ask, I think:
   - Changing or even caring about "window" is probably a mistake.
       Almost everyone is mistaken about what "window" does, probably
       because of confusing documentation that is partly my fault
       and because of changes since the documenting.  "Window" only
       affects the duration of what you might call the "penalty box."
       A large stream of identical responses are is dropped for
       "window" seconds after it stops being large.

   - The right IP prefix for an ISP depends on the size of IP address block
       it gives its customers.  If customers get /32s, then that is
       the right prefix.  If customers get /24s, then a customer with
       one infected host seems likely to have more than one and so an
       IPv4 prefix of 24 sounds reasonable.

   - The right rate limit depends on what your users do with your recursive
       DNS servers.  If their DNS requests are for desktop systems or
       tablets, then a limit of a little below the number of identical
       host names in URLs in web pages sounds right.  But if their DNS
       requests are for SMTP servers (mail receivers) using a DNSBL
       and getting substantial bursts of spam, then you might want a
       rate limit of about their incoming SMTP rate.

       DNSBL users might want to set the optionally separate
       nxdomains-per-second limit higher, legitimate mail should
       generate a lot of DNSBL NXDOMAIN responses.

       100 requests/second is high even for an SMTP server, since it
       would imply 100 mail/second or 8 million mail/day.  The RRL
       limit is NOT a simple, firewall rate limit but a limit on
       identical responses.  100 total qps might not be too generous
       if RRL counted all DNS queries the same like a simple firewall
       rule, but in most cases 100/sec is wrong for RRL.  A single /32
       is unlikely to legitimately query "facebook.com A" even 10 times
       per second even if the total query rate for the (possibly NAT'ed)
       /32 is more than 100 qps.


I'd take all of that with a grain of salt and concentrate on what
"log-only" says would happen with various limits if you were not using
"log-only".


Vernon Schryver    vjs at rhyolite.com