Response Rate Limiting (RRL)
Response Rate Limiting – Overview
A DDoS attack is designed to disable DNS servers by overwhelming them with superfluous queries to the point where they can’t correctly direct web traffic, or the strain on bandwidth renders them non-operational. Another cyberattack technique that can be even more damaging than a DDoS hack is a reflection attack, where a number of authoritative servers – these are the primary servers for a DNS zone, storing the definitive versions of all records in that zone – are used to attack a single entity. This is done by sending queries spoofed as the target to authoritative servers in order to generate responses at a rate potentially orders of magnitude greater than would be possible in a generic DDoS attack (known as “amplification”).
Authoritative name servers are designed to provide answers in response to questions asked about names in a zone. So, in a reflection attack, the attacker can leverage many authoritative servers and pick servers that have far more capacity than the target itself. Thus, it becomes possible to overwhelm the target with UDP responses to questions it never asked. The sheer volume of traffic that results can quickly overwhelm routers, firewalls or other perimeter defense tools, with the result that the target is brought down.
When you look at addressing DDoS attacks against DNS infrastructure, the critical issue becomes separating valid queries from malicious queries. With DNS, we can’t simply block all the packets; we need to sort the good form the bad. Attackers are very good at making their queries look legitimate, so the trick is to look at the pattern, rate and signature of queries more than at the queries themselves. This is the fundamental concept behind response rate limiting (RRL).
RRL Basics
If a DDoS attack is like a single customer of a doughnut store buying up all of the doughnuts, so that no one else can have any, then RRL can be understood as limiting each customer to only one doughnut of each flavor per day. If each person can buy only one chocolate and one glazed donut on a given day, then the DDoS attack can’t do as much damage.
RRL depends on the concept of a token bucket to limit how many responses the DNS server will send to any single client. A configuration on the DNS server creates a token bucket for each client that contains, for example, five tokens and adds five more each second. The server takes out one token for each query response it sends to the client and/or for that specific record. Figure 3-1 illustrates the setup.
Figure 3-1: The token bucket on the authoritative isc.org name server prevents sending responses to the same client too frequently. In this example, the isc.org name servers are being leveraged in a Combination attack leveraging both a reflection attack and an amplification attack.
Once the bucket is empty, it takes 15 seconds to refill. In the meantime, the server sends truncated responses to the client instead of full responses. Truncated responses prevent the amplification that attackers get from full query responses. Add in the 15-second delay preventing the volume of queries from overwhelming the server, and presto! Suddenly the DNSSEC server is no longer useful in amplification attacks.
This tokenization strategy ensures that when legitimate clients happen to empty their own token bucket, waiting 15 seconds to try again isn’t too much of an imposition. Alternately, the client can retry the query right away over TCP.
Now that we have this core mechanism of Resource Rate Limiting, we can leverage other tools to help identify the malicious packets beyond simply the rate of queries. And, we can use those tools to tune the rate limiting. This can include tools that look at source identity, can detect malicious packet forms or judge packet correctness, or tap into threat intelligence sources or other threat analytics.
RRL also provides a “monitoring mode,” which can be highly a useful tool in defending a network purely from an information gathering standpoint. It also allows administrators to tune the rules to ensure they are limiting attacks while avoiding interference with legitimate queries. By utilizing monitoring and verification tools, it becomes possible to address attacks as they happen, while also providing the best level of service to legitimate DNS customers. This applies whether an attack is targeting the operability of a specific authoritative DNS server, or when the goal is to use an authoritative server to amplify attacks against third party targets.
It is commonly reported that most organizations that implement RRL see an immediate positive impact to their query rates and improvement of performance for legitimate traffic.
Figure 3-2 below shows the published impact when the F-Root Server implemented RRL in 2013
Figure 3-2: RRL also provides a “monitoring mode,” which can be highly a useful tool in defending a network by providing administrators information to tune the rules to limit attacks while avoiding interference with legitimate queries.
