Knowledge Base ISC Main Website Ask a Question/Contact ISC
A Quick Introduction to Response Rate Limiting
Author: ISC Support Reference Number: AA-01000 Views: 3558 Created: 2013-06-12 18:56 Last Updated: 2013-10-01 16:00 0 Rating/ Voters

What is RRL?

RRL, or Response Rate Limiting, is an enhancement to the DNS protocol which serves as a tool for mitigating DNS amplification attacks

At this time, RRL implementation is only recommended for authoritative servers.

How can I get RRL?

Response Rate Limiting functionality is included in open source BIND from version 9.9.4 onwards (it is enabled when building BIND by specifying configure option --enable-rrl).  RRL is already available in subscription versions of BIND - for more information about our subscription versions, please visit  Unsupported patches that add RRL functionality to earlier versions of BIND can be downloaded from

The Problem

DNS is easily used for reflected denial-of-service (DOS) attacks, with three factors combining to make it a popular choice.

  1. UDP, which is commonly used for DNS traffic, was not designed with source validation in mind.  Consequently BIND responds to packets with a forged source the same as it does to legitimate packets.  An attacker can therefore send DNS queries forging an IP address of the victim as the source address, causing the DNS server to send the replies to the victim.  This is a "reflected attack".
  2. Most ISPs do not check the source address of packets that they send to ensure that the source address matches a network block managed by that ISP.  This allows forged-address attacks to be launched from a large portion of the Internet.
  3. Small DNS queries can generate large responses, allowing the attacker to send a lot less traffic than the victim receives, amplifying the attack.  For example, an EDNS0 query for of type ANY is 36 bytes long (not counting the UDP, IP, and Ethernet headers) and triggers a response that is 3,576 bytes log (not counting UDP, IP, and Ethernet headers.)  By reflecting, an attacker can cause a nearly 100x increase in the amount of traffic that they are directing at the victim and they can conceal the source of the attack as well.

A Solution

While we cannot know which source addresses are forged and which are not, we can look at the pattern of requests and responses and infer with a high degree of confidence when there is an attack.  We can then use this information to throttle responses, cutting off the attack.  Incoming queries are NOT throttled by RRL.

The Results

Operators of large authoritative servers have reported huge reductions in network traffic and server load 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.  The impact on legitimate traffic has been minimal.

Sample BIND RRL configuration

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, let's say your authoritative server for is being flooded with queries for the address record of with the DO (DNSSEC OK) bit set. is DNSSEC-signed so our reply packet size will be somewhat large.  In the query log,  you are seeing something like this:

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 but given the frequency of the repeated query, it would be reasonable to suspect that these queries are spoofed and is the target of a DDOS attack.

If this is your first use of RRL, perhaps you would like to test its behavior before actually limiting responses -- you can see what RRL would do before actually having it limit responses.  You can do this by setting "log-only yes" during configuration.  Edit named.conf and add the following rate-limit clause in your global options:

options {
    directory "/var/named";
    rate-limit {
        responses-per-second 5;
        log-only yes;

 After a configuration reload, you will now see messages such as the following in your logs:

07-Jun-2013 12:41:42.336 queries: info: client ( query: IN A +ED (
07-Jun-2013 12:41:42.336 query-errors: info: client ( would rate limit slip response to for IN A  (3ee9836b)

When you feel comfortable with what RRL will actually be limiting, remove the "log-only yes" and after a reload, you will begin to see:

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.

© 2001-2013 Internet Systems Consortium

Feedback 10
  • #
    [ speednic]: RRL rate-limit don´t work 2013-09-29 00:18

    I have seen that BIND 9.9.4 is available now, I have installed it but the same problem - unknown option rate-limit

    Sep 29 00:09:52 cluster02 named[7038]: starting BIND 9.9.4 -c /etc/bind/named.conf
    Sep 29 00:09:52 cluster02 named[7038]: built with defaults

    are there some hints to activate RRL ?

    thx alex

  • #
    [Cathy Almond]: Re: RRL rate-limit don´t work 2013-10-01 12:20

    Apologies, although the option to enable RRL was included in the README file in the tarball, this step was not clearly explained as necessary in this article. We've updated this article and added a new FAQ to explain this. Please build BIND with --enable-rrl if you wish to use this functionality.

  • #
    [ Martin]: 9.9.4 - unknown option 'rate-limit' 2013-09-20 16:45

    # named -v
    BIND 9.9.4 (Extended Support Version)
    in options section:
    rate-limit {
    responses-per-second 5;
    log-only yes;
    The result after service named restart:
    Error in named configuration:
    /etc/named.conf:47: unknown option 'rate-limit'

  • #
    [Cathy Almond]: Re: 9.9.4 - unknown option 'rate-limit' 2013-10-01 12:33

    Please build BIND with --enable-rrl if you wish to use this functionality.

  • #
    [ alan]: enabling rrl 2013-09-20 00:42

    A look at configure --help indicates that the solution is --enable-rrl. This also doesn't show up in the config status that's supposed to show what options are available and what are configured (it seems to be very short on those actually).

  • #
    [Cathy Almond]: Re: enabling rrl 2013-10-01 16:44

    Thanks for commenting on this - I've added the specific request that we show whether or not rrl is enabled to an existing ticket (RT #34796) for improving the information provided in the configuration summary.

    For future reference, please see for information on where to report bugs and request new features.

  • #
    [ Alan]: rate-limit invalid 2013-09-20 00:39

    I also just installed the release 9.9.4 and got the unknown option error

  • #
    [Cathy Almond]: Re: rate-limit invalid 2013-10-01 12:27

    Please build BIND with --enable-rrl if you wish to use this functionality.

  • #
    [Renato]: BIND RRL configuration 2013-08-02 13:51

    I configured the "rate-limit" on my server 9.9.3-P2 and got the following error:
    "config: error: /etc/named.conf: 52: unknown option 'rate-limit'"
    I have found no reference on the RRL "9.9 BIND Administrator Reference Manual"

  • #
    [Cathy Almond]: Re: BIND RRL configuration 2013-10-01 12:23

    Apologies - we published this article too hastily, omitting the information that Response Rate Limiting is only available in BIND 9 from version 9.9.4 onwards. We've updated the article to explain this, as well as providing links to the unsupported open source patches that can be used until BIND 9.9.4 is available. (Subscription versions of BIND 9.9.3 already have RRL built-in.)

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