Knowledge Base ISC Main Website Ask a Question/Contact ISC
Using the Response Rate Limiting Feature
Author: ISC Support Reference Number: AA-00994 Views: 64814 Created: 2013-06-07 15:16 Last Updated: 2018-04-24 23:11 100 Rating/ 1 Voters

RRL, or Response Rate Limiting, is an enhancement to the DNS protocol which serves as a mitigation tool for the problem of DNS amplification attacks.  At this time, RRL implementation is only recommended for authoritative servers. This article explains how to use RRL in BIND 9.10 and later versions (and in BIND 9.9 after building a version with RRL explicitly enabled).

DNS reply packets are usually larger than query packets and (depending on the question asked) can be much larger.  By sending a question that is known to have a large reply packet, an attacker can multiply the effectiveness of attacking target machines by sending them garbage data.  The attacker sends out a large number of DNS queries that are forged to look like they were sent by the victim, so that the large response packets get sent to that victim.  This is the classic DNS DDoS.  For more information on these attacks, please see:

Excessive almost identical UDP responses can be controlled by configuring a rate-limit clause in an options or view statement. This mechanism keeps authoritative BIND 9 from being used as part of a DNS amplification attack. If a response to a legitimate client is blocked, it will retry with UDP or TCP. The RRL mechanism is intended for authoritative name servers. While it will work on recursive servers, it is more likely to generate false positives there. Limiting access to a recursive server is a better means of preventing their abuse.

Response rate limiting uses a ”credit” or ”token bucket” scheme. Each combination of identical response  and client identity has a conceptual "account" that earns a specified number of credits every second. A prospective  response debits its account by one. Responses are dropped or truncated while the account is negative.  Responses are tracked within a rolling window of time which defaults to 15 seconds, but can be con-  figured with the window option to any value from 1 to 3600 seconds (1 hour). The account cannot  become more positive than the per-second limit or more negative than window times the per-second  limit. When the specified number of credits for a class of responses is set to 0, those responses are not  rate limited. Further details and nuances of the RRL algorithm can be found in Section 6.2 of the BIND 9.10 ARM.

Operators of large authoritative servers have reported huge reductions in network traffic after enabling RRL.  Additionally, these servers are no longer seen as participating in abusive network behavior as fewer illegitimate responses are reaching their intended targets.

Response Rate Limiting is an optional feature which is turned off by default.  To enable RRL, a rate-limit clause must be added to an options or view statement within named.conf.

As a very simple example scenario, an authoritative server for is being flooded with queries for the address record of with the DO (DNSSEC OK) bit set. is DNSSEC-signed so the reply packet size will be somewhat large.  These entries are being seeing in the query log:

07-Jun-2013 12:27:34. 102 queries: info: client       ( query: IN A +ED (
07-Jun-2013 12:27:41. 606 queries: info: client       ( query: IN A +ED (
07-Jun-2013 12:27:59. 196 queries: info: client       ( query: IN A +ED (

The queries are appearing to originate from  However, due to the large number of repeated queries being logged, is the likely target of a DDoS attack.

To enable RRL to defend against this, edit named.conf and add the following   rate-limit clause to the global options:

options {
          rate-limit {
              responses-per-second 10;

After a configuration reload by use of "rndc reload" or a restart of named, log entries similar to the following will appear as responses are dropped:

07-Jun-2013 12:44:44.868 queries: info: client       ( query: IN A +ED (
      07-Jun-2013      12:44:44.869 query-errors: info: client       ( rate limit drop response to for IN A  (3ee9836b)

RRL is highly configurable to combat many attack scenarios.  We   recommend reading the Response Rate Limiting section of the BIND9   Adminstrator Reference Manual (ARM) for an in-depth review of the RRL   configuration options.

Tip:  To look at RRL behavior before actually limiting responses, set "log-only yes" as below during configuration and look at your query logs after restart. Remember that BIND will write all log files into the directory named by the "directory" option, so be careful to specify a suitable absolute directory path among your options.

options {
           directory "/var/named";
           rate-limit {
              responses-per-second 10;
              log-only yes;
Additional RRL configuration options

Other options that can be used in a rate-limit block include qps-scale, errors-per-second, nxdomains-per-second, all-per-second, domain, max-table-size, min-table-size, and log-only. See the BIND ARM for documentation of these less-frequently-needed RRL options. The complete list of contents permitted in a rate-limit block is in section 6.2.15 of the ARM; the instructions for how to use them are in section

The ARM published with 9.10.0 erroneously contains documentation of some semi-experimental RRL features that were not included in the 9.10.0 release.  The documentation will be corrected in our 9.10.1 release.

© 2001-2018 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback 8
  • #
    [Irvine Lee]: Rate Limiting for defense 2015-04-22 16:02

    Hi all,
    We have a recursive server with BIND9.10.1.
    recently, it happens very frequently for a request timed out with 2 seconds.
    My question: may we use Rate Limiting for defense? Is there any other way to defense, e.g: build up a certain rule in the ip tables.

  • #
    [Cathy Almond]: Re: Rate Limiting for defense 2015-05-05 13:05

    Response Rate Limiting is primarily intended for Authoritative servers. If you are experiencing problems on your Recursive server, Recursive Client Rate Limiting is likely to be more suitable for your needs:

    The article above details how the experimental code works that has been trialed in the BIND subscription version. This code is also available upon request as an experimental build of BIND to anyone who would like to try it and provide us with feedback (and we also intend to include it in our next openly-available production versions of BIND).

    Please complete the enquiry form at if you are interested in trialing this code.

  • #
    [ ]: Selective rate limiting 2015-03-13 14:23

    I want to rate limit with the exceptin of two of my very busy email spam firewalls. Is it possible to exclude an ip from rate limiting while limiting all other IPs if necessary? Thanks,

  • #
    [Cathy Almond]: Re: Selective rate limiting 2015-03-19 18:43

    You can use the exempt-clients clause to do this:

    exempt-clients { address_match_list }

    Details are available in our Adminstrator Reference Manual (ARM) that is shipped in the ~./doc/arm/ directory of the BIND tarball and also online - see:

  • #
    [ James Watt]: Is this a per source IP limit or global? 2014-12-27 08:06

    Limiting to 10 per second per connection isn't bad, but if this is a global settings and I'm getting flooded by 1 attacker, it's going to stop legitimate users from accessing DNS.

    Is this a global setting or a per source IP? Thanks.

  • #
    [Cathy Almond]: Re: Is this a per source IP limit or global? 2014-12-29 13:23

    This is per answer and per client. In the article it says "Each combination of identical response and client identity..." The limiting is applied on that basis. In the example in the article, the limit is applied to responses to - but should not impact other clients making reasonable volumes of queries that would elicit the same answer.

  • #
    [ stendstend]: rate-limit 2014-05-22 07:55

    Do not work following construction on BIND 9.9.5 (Extended Support Version):
    options {

    rate-limit {
    responses-per-second 10;
    rate-limit {
    responses-per-second 3;
    when named start error message "not option domain"

  • #
    [Brian Conry]: Re: rate-limit 2014-08-06 21:26


    Yes, we inadvertently left in documentation of some semi-experimental features of RRL that we chose not to include in 9.10.

    The article has been corrected.

    We apologize for the confusion.

    Brian Conry

Quick Jump Menu