Using the Response Rate Limiting Feature

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: What is a DNS Amplification Attack?

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 configured 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 Administrator Reference Manual (ARM) for an in-depth review of the RRL configuration 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.