[ratelimits] Double CPU usage with RRL

Vernon Schryver vjs at rhyolite.com
Tue Oct 15 21:14:31 UTC 2013


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

>    I changed min-table-size 6000, removed max-table-size and 
> nxdomains-per-second. I also adjusted responses-per-second to 30.
>    CPU seems to be doing fairly well. Still running in log-only mode.

Was (or is) there enough log activity to explain the 100% CPU hit?
Did you try the -U1 suggested by someone at ISC?


>    Does this latest log message indicate that I should be increasing my 
> min-table-size to 19000?
>
>    15-Oct-2013 10:08:02.964 rate-limit: info: increase from 18000 to 
> 19000 RRL entries with 13001 bins; average search length 1.9

min-table-size and max-table-size are unlikely to have effects.
Min-table-size only affects the initial size of the hash table.  Changing
it makes sense only if your DNS server is often restarted, and if it
is quite busy, so that avoiding expanding the hash table is worthwhile.
Max-table-size is useful only to prevent bloating of the hash table
should someone try to resolve a zillion different names.  When the table
reaches the maximum limit, entries younger than the window are used
instead of making additional entries.
I probably should not have included those 2 parameters.  I thought
expanding the table would be more expensive that it turned out to be.
The expansion is a lazy thing that is cheap when at most one expansion
happens per window seconds.  A first expansion within window seconds
consists of using both the too small old and bigger new tables until
all of the {qname,qtype,IP,...} entries have died in the new table or
been copied into the new table as a side effect of being refreshed.
Window seconds after the larger table is created, the old one is
discarded.  Its remaining entries are reused as they fall out of the
LRU list.

  ..............


} From: "Manson, John" <John.Manson at mail.house.gov>

} RRL is not specified for a recursive name server.

Paul and I designed and recommend RRL for authoritative servers to
keep authorities from being used in DNS reflection DoS attacks.

Recursive servers should generally not be visible to the Internet (as
opposed to private small-I internets), and so generally do not need
the protection from DNS reflection DoS attacks that is excuse for
burdening a DNS server with the costs of RRL.  Recursive servers can
see legitimate traffic that looks like reflection attacks, and so RRL
slows that legitimate traffic.  However, a recursive server that is
exposed to the Internet requires defenses including against including
reflection attacks.  An exposed recursive server with RRL is far better
than an undefended exposed server including accounting for the effects of
RRL on those legitimate bursts.  For an independent but similar
view, please read Google's words about the rate limiting that Google
does on their recursive servers at
https://developers.google.com/speed/public-dns/docs/security#rate_limit

The Open Resolver Project http://openresolverproject.org/
seems to be currently reporting more than 28 million open recursive
resolvers.  http://openresolverproject.org/breakdown.cgi
There is no excuse for most of those 28M to be open, but I bet there
are millions that are like the open recursive resolvers of Google,
OpenDNS, and evidently Sonic.net that must be open for various good
and compelling reasons.  They need protection.


Vernon Schryver    vjs at rhyolite.com


More information about the ratelimits mailing list