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.
- 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".
- 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.
- 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.
© 2001-2013 Internet Systems Consortium
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