RRL BIND Recursive

Mahdi Adnan mahdi.adnan at outlook.com
Wed Oct 19 09:38:51 UTC 2016

Thank you for your reply.I'll look into RCRRL.Im getting huge number of bogus requests that causing SERVFAIL like "snwjkjsdw.com" and so on, and thats why im trying to use RRL, all those requests are coming from my internal clients.rnds status:
version: 9.9.4-RedHatCPUs found: 48worker threads: 48UDP listeners per interface: 12number of zones: 5debug level: 0xfers running: 0xfers deferred: 0soa queries in progress: 0query logging is OFFrecursive clients: 870/99900/100000tcp clients: 3/100

if you have any other idea to block such requests that would be helpful. 



    Mahdi A. Mahdi

> Subject: Re: RRL BIND Recursive
> To: bind-users at lists.isc.org
> From: cathya at isc.org
> Date: Wed, 19 Oct 2016 10:05:10 +0100
> 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
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20161019/bec1af2b/attachment.html>

More information about the bind-users mailing list