Knowledge Base ISC Main Website Ask a Question/Contact ISC
Using the Response Rate Limiting Feature in BIND 9.10
Author: ISC Support Reference Number: AA-00994 Views: 6544 Created: 2013-06-07 15:16 Last Updated: 2014-08-06 21:26 0 Rating/ 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 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: https://kb.isc.org/article/AA-00897/11/What-is-a-DNS-Amplification-Attack.html

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 example.com is being flooded with queries for the address record of testhost.example.com with the DO (DNSSEC OK) bit set.  example.com 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 1.2.3.4#58540       (testhost.example.com): query: testhost.example.com IN A +ED (1.2.3.4)
07-Jun-2013 12:27:41. 606 queries: info: client 1.2.3.4#55979       (testhost.example.com): query: testhost.example.com IN A +ED (1.2.3.4)
07-Jun-2013 12:27:59. 196 queries: info: client 1.2.3.4#47516       (testhost.example.com): query: testhost.example.com IN A +ED (1.2.3.4)
 

The queries are appearing to originate from 1.2.3.4.  However, due to the large number of repeated queries being logged,  1.2.3.4 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 1.2.3.4#57114       (testhost.example.com): query: testhost.example.com IN A +ED (1.2.3.4)
      07-Jun-2013      12:44:44.869 query-errors: info: client 1.2.3.4#57114       (testhost.example.com): rate limit drop response to 1.2.3.0/24 for       testhost.example.com 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 6.2.16.21.


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-2015 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

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 4
  • #
    [ 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 1.2.3.4 - 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

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

    rate-limit {
    domain first.example.com;
    responses-per-second 10;
    };
    rate-limit {
    domain second.example.com;
    responses-per-second 3;
    };
    };
    when named start error message "not option domain"
    Thanks.

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

    Hi,

    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.

    Thanks,
    Brian Conry

Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu