RRL BIND Recursive

Cathy Almond cathya at isc.org
Wed Oct 19 09:05:10 UTC 2016


On 18/10/2016 07:37, Mahdi Adnan wrote:
> Hi,
> 
> I have a few servers running a recursive DNS bind service, i configured
> one of the servers to limit the rate of requests.
> my configuration is:
> 
> rate-limit { log-only yes; errors-per-second 8; nxdomains-per-second 8;
> ipv4-prefix-length 32;
> 
> As soon as i apply these changes my server drop 90% of the requests
> after a minute or two.
> do you have any idea why is this happening ?
> bind version is :
> BIND 9.9.4-RedHat-9.9.4-29.el7_2.4

This is a recursive server, so I think you've chosen the wrong tool -
Response Rate Limiting (RRL) is applied to responses - so all of the
work to get the response for a client is done before the rate limiting
being applied - you want something that prevents that, not just the
responses.

Have a look a recursive client rate limiting instead:
https://kb.isc.org/article/AA-01304

(You're probably going to have to upgrade your BIND to get it).

Moreover, you have "ipv4-prefix-length 32;" (the default is 24 and is 24
for a reason - the overhead of managing all the rate limited buckets is
going to be greater when you have more granularity.)

I would guess that by adding RRL, even log-only, to a recursive server
that is already under stress, that you've made it harder for it to
function and have tipped it over the edge and you now have a build-up of
recursive clients (backlog) to the point where named isn't able to
respond to incoming queries quickly enough.  It's also possible that
your named isn't able to read queries from the UDP socket fast enough,
and you have the buffer there overrunning and dropping queries.

rndc status will show you if you're hitting the limit of recursive
clients.  If you are, increasing it probably isn't going to help you -
you need to deal with why you have the backlog (but having a limit that
is bigger than 1000 will get you a soft limit as well as a hard limit,
so reaching the limit should cause SERVFAIL rather than drops).

Cathy




More information about the bind-users mailing list