[ratelimits] Double CPU usage with RRL

[Vernon Schryver]

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

> I'm seeing approx double the amount of CPU usage when RRL is enabled.
> CPU usage is normally around 50%-60% for named but when RRL is enabled
> it jumps to 110%-130%. Just wondering if this is expected and I just need
> to throw more CPU at it. This is on a recursive name server btw.

A 100% penalty sounds very high based on what I understand of the BIND9
code invoked o answer from the cache.  Never mind the even higher costs
of recursing.  I think the RRL hash table is significantly faster than
the BIND9 red/black tree code, and a response needs only one RRL lookup
but often more than one forest expedition.

Do you have logging turned high enough to record every RRL action?
Logging eats lots of CPU cycles.


>        rate-limit {
>                responses-per-second 60;
>                nxdomains-per-second 0;
>                ipv4-prefix-length 32;
>                log-only yes;
>                min-table-size 200000;
>                max-table-size 300000;
>        };

Why such a high general RRL limit?  Are some of your users hitting it
with DNSBL traffic?

Why turn off NXDOMAIN rate limiting?
As long as DNSSEC is rare, that might not matter.
http://scoreboard.verisignlabs.com/percent-trace.png
http://scoreboard.verisignlabs.com/
When registrars are forced by ICANN to compete with their 
profitable commercial PKI "sidelines" by supporting DANE and TLSA,
http://www.internetsociety.org/deploy360/blog/2013/09/icanns-2013-raa-requires-d
omain-name-registrars-to-support-dnssec-ipv6/
that might change.  A signed NXDOMAIN is plenty big enough to cause
DNS reflection DoS mischief.

I trust those changes to the default table sizes are justified by
measurements.  A DNS server that needs RRL table space to remember at
least 200,000 responses per several seconds must be doing more than
20,000 qps.


Vernon Schryver    vjs at rhyolite.com