This is a Canonical Question about rate limiting in the ISC BIND nameserver software.

Recently I've heard of BIND's rate limiting features. DNS RRL in particular seems to be becoming more commonplace.

I'm a little bit confused. Some of the documentation seems to say that these features should not be used with recursive DNS servers, but other documents very specifically address recursive DNS infrastructure. Who is right?


While I dearly wish that ISC would document these features better for the sake of users with an experience level below "expert", that is wishful thinking. There are two separate implementations of rate limiting within BIND as of 9.11, and they are targeted at solving two completely different problems.


The first form of rate-limiting is DNS Response Rate Limiting, usually referred to as DNS RRL. You can read more about the specification here. It is implemented by multiple authoritative nameserver daemons and is not specific to ISC BIND.

DNS RRL is designed to protect authoritative DNS servers, but BIND will not stop you from activating this feature on recursive servers. Many users stumble across the related options in the BIND documentation and assume that these are intended for use with recursive DNS servers. This is not the case. Don't enable this on a recursive server.

If you're running a server that provides authoritative data and recursion, you shouldn't be doing that anyway. By running that configuration you have accepted the additional problems that come with it. We can't help you with that.


The ISC knowledgebase article for the BIND's fetchlimit code is titled Recursive Client Rate limiting in BIND 9.9.8 and 9.10.3, which makes things confusing. This has nothing to do with DNS RRL.

Unlike DNS RRL, the fetchlimit code is designed to address DNS attack strategies which cause a recursive server to participate in attacks against authoritative servers. Specifically, these options are designed to reduce the number of simultaneous queries that your recursive server will make to individual authoritative DNS server IPs, and/or individual DNS domains. This makes your server less attractive for use in Psuedo Random Subdomain attacks (against others), and also helps to limit the impact to your own DNS servers when they are being used in this kind of attack. (ephemeral port exhaustion, etc.)


While this Q&A is provided to help clarify the frequently confused differences in the ratelimiting code provided by ISC BIND, neither of these are comprehensive solutions to abuse of a recursive DNS server. Only the latter is intended for use with a recursive DNS server, and even then it is designed to address a specific form of attack that frequently plagues operators of high volume recursive DNS environments.

If your recursive DNS environment is being used to attack others, BIND's rate limiting features are a red herring unless you have already implemented all of the other best practices. (don't run an open resolver, avoid internet facing interfaces on recursive DNS servers in general, drop traffic from unknown networks before it hits the recursive server, etc.) Rate limiting is a value add that you apply in addition to your other abuse reducing strategies. It is not a replacement for them.

| improve this answer | |
  • 2
    I would shorten Don't enable this on a recursive server unless you're done a significant amount of research on how this feature actually works. into just Don't enable this on a recursive server. – kasperd Jan 10 '16 at 16:41
  • @kasperd I was trying to ease stubborn people into actually reading it, but that's fine. Done. – Andrew B Jan 10 '16 at 16:42
  • 2
    I'm all for people reading it. But the original wording could have given the impression it was acceptable to enable the feature on a recursive server, once you have read how it works. – kasperd Jan 10 '16 at 16:46
  • Yeah, fair enough. – Andrew B Jan 10 '16 at 16:48
  • @kasperd actually there are folks that have used DNS RRL on recursive servers with some success. – Alnitak Jan 11 '16 at 12:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.