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.

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 isc.org 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 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 our reply packet size will be somewhat large.  In the query log,  you are seeing something like this:

The queries are appearing to originate from 1.2.3.4 but given the frequency of the repeated query, it would be reasonable to suspect that these queries are spoofed and 1.2.3.4 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:

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

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:

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.