[ratelimits] new RRL patches with small bug fix

[Vernon Schryver]

> From: Geert Jan de Groot <GeertJan.deGroot at xs4all.nl>

> > DNS RRL is not recommended for recursive servers, because DNS clients
> > can send bursts of identical, legitimate requests.  
>
> I'm surprised by this. I thought that something like this would work,
> and it did when I tested it:
>
> acl clients {
>         127.0.0.1/32;
>         192.0.2.0/24;
> 	...
> };
>
> options {
> 	...
> 	allow-recursion { 
> 		clients; 
> 	};
>         rate-limit {
>                 responses-per-second 5;
>                 window 5;
>                 exempt-clients { 
> 			clients; 
> 		};
>         };
> };
>
> What am I missing?

(The "window 5;" setting is probably not needed, because you'll see
no difference with the default of setting 15.)

I might not understand that configuration.  If I do, there are 2 issues:

  - If the only allowed DNS clients use trusted local IP addresses, 
     then why is RRL needed?  Why pay the administrative costs
     of another mechanism that can be misconfigured or have bugs?

  - What if one of those local DNS clients is an HTTP client (web
     browser) that encounters 10 <IMG> tags on a page?  Or an SMTP
     server (mail receiver) that receives 10 copies of spam from the
     same sender or containing the similar URLs in the body?  The DNS
     client will be rate limited.  With the default "slip 2", its 6th
     DNS request will be truncated and it will immediately retry with
     TCP.  Its 7th and subsequent requests will be discard and then
     retried with UDP after a timeout.  The retry will be "slipped",
     retried with TCP, and answered.

     If the client is a SMTP server, slowing down spam might be a
     good thing, unless other mail is also slowed indirectly, perhaps
     by process or thread limits in the SMTP server.  Slowing down
     browsers is usually unpopular.

The purpose of RRL is mitigating DNS reflection Denial of Service
attacks.  Authoritative DNS servers generally receive requests only
from recursive servers and recursive servers should have caches that
prevent repeated requests.  RRL is widely recommended for authoritative DNS
servers.

However, DNS stubs or resolver libraries in applications generally
lack caches and so repeat requests.  That means that RRL can cause
complaints when used on recursive servers.  Using RRL on private
recursive resolvers might allow fewer problems than not using RRL at
large ISPs.  On the other hand, it sounds better to me to prevent
internal security problems at their sources at small sites.

The recommend solution for recursive servers open to the Internet is
closing them.  RRL cannot be recommend on open recursive servers,
because it can cause complaints.  However, any complaints about RRL
on an open recursive server might be more than balanced by a lack of
complaints from victims of DoS attacks using the server.  If are going
into the open recursive server business, you probably want more
complicated rate limits than RRL.


Vernon Schryver    vjs at rhyolite.com