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 184.108.40.206#58540 (testhost.example.com): query: testhost.example.com IN A +ED (220.127.116.11)
07-Jun-2013 12:27:41. 606 queries: info: client 18.104.22.168#55979 (testhost.example.com): query: testhost.example.com IN A +ED (22.214.171.124)
07-Jun-2013 12:27:59. 196 queries: info: client 126.96.36.199#47516 (testhost.example.com): query: testhost.example.com IN A +ED (188.8.131.52)
The queries are appearing to originate from 184.108.40.206. However, due to the large number of repeated queries being logged, 220.127.116.11 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:
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 18.104.22.168#57114 (testhost.example.com): query: testhost.example.com IN A +ED (22.214.171.124)
07-Jun-2013 12:44:44.869 query-errors: info: client 126.96.36.199#57114 (testhost.example.com): rate limit drop response to 188.8.131.52/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.
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 184.108.40.206.
© 2001-2015 Internet Systems ConsortiumPlease 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.