This article discusses DNS reflection, a technique used in DDoS attacks. DNS rate limiting can be used as mitigation against DNS reflection attacks. This paves the way to our new tool DNS Hammer. The program can help auditing a DNS server’s rate limiting configuration.

A dedicated web site https://www.dnshammer.com offers the tool for download and instructions how to use it.

Summary for busy readers (tl;dr)

DNS Servers without active rate limiting can be an involuntary contributor to a distributed denial of service attack (DDoS). The new tool DNS Hammer can help in the review of a DNS server’s rate limiting configuration.

Another day in the office

When checking a few log files, I noticed a short but significant spike in UDP traffic. Interested readers find a packet sample in the download section. Someone had delivered a ton of unwanted DNS and LDAP responses to one of our systems.  The original requests were modified, so that the IP packets would show one of our source IP addresses as source. As a result the servers would deliver the result to us.

This technique of IP spoofing is long known and widely used by shady individuals in the Internet. The attackers send a rather short request of 60-80 byte and generates a longer response that can reach 2000 or more byte. The trace file shows responses exceeding 4000 byte in length, amplifying the source traffic by a factor of 50. This attack is called DNS reflection and often used for distributed denial of service attacks, or DDoS for short.

The majority of packets were DNS packets with a bit of CLDAP in the mix. Since DNS made the majority of packets, I took a closer look at DNS.

DNS Reflection

If you open the trace file with Wireshark, the display filter dns will show that all DNS responses carried information about the domain peacecorps.gov. There are no DNS requests present, which confirms that we are indeed hit by a DNS reflection attack. The flood of DNS responses came not from one single source, but from many (hence it’s called a “distributed” attack).

We have to assume that the source IP addresses seen in the capture belong to open resolvers. Most DNS servers can only be used by selected users. The majority of Internet service providers configure their DNS servers to respond only to queries send by their customers. Open resolvers can be used by anyone. Operators running an open resolver should enforce a rate limit that throttles the clients to something reasonable when it comes to the frequency of DNS requests. Without a rate limit a DNS server can obviously be abused to play a role in DDoS attacks. Please note that a good number of open DNS servers are a result of an involuntary misconfiguration, and not by actual choice of their respective administrators.

A DNS response also includes the original query. Here a few details on the DNS responses:

• All queries were made for the ANY record.
• Each response for an ANY record delivers an individual set of resource records with a wide range of information.

ANY records do not deliver the specific information that a computer needs to deliver an e-Mail or to access a web site. They might be helpful in certain troubleshooting scenarios, but not for routine operations.

The fraudulent DNS requests were most likely triggered by a botnet. In other words: Someone instructs compromised computers to send fake requests to open DNS servers. The servers in turn would deliver all their responses to us. The following picture tries to visualize the events. The trace file shows the final result, symbolized as red lines in the graphic.

DNS Reflection

Note for fellow nerds and propeller heads: RFC 8482 covers ANY records in greater detail. An article on the Cloudflare Blog summarize the RFC to “Saying Goodbye to Any”

Please note, that ANY records are not the only “interesting” record types for an attack. If a domain is secured by DNSSEC, the search for a mail server (referenced by an MX record) can easily generate over 1’000 bytes of traffic. DNSSEC adds a digital signature to the responses. This makes it virtually impossible for an attacker to redirect traffic from a benign server to an evil clone.

DNS Reflection through authoritative name servers

The domain peacecorps.gov and the open DNS servers made it easy for the attackers by dispensing large responses to the ANY query. Theoretically, an attacker could skip the open servers and go for an authoritative name servers.

Authoritative Name Servers

Please remember, that DNS is a distributed database: The information provided by DNS is not kept in a single server. Instead, all the available information is stored in a vast number of servers. An authoritative name server holds a master copy for one or more domains. Other servers, like your local DNS server, will cache the responses for some time and hand out answers, but they are not authoritative.

Please note, that an attacker could skip the open resolvers and send the forged queries to an authoritative name server instead.

DNS Reflection via Authoritative Servers

DNS Rate Limiting

Clearly, if you operate a DNS server, you don’t want to be part of a DDoS attack.

Several DNS implementations like BIND can be configured to limit the number of responses. This feature, rather intuitively named DNS rate limiting, is supported by widely used DNS implementations like BIND or the Microsoft server. Unfortunately, only a small number of DNS implementations enforce a rate limit.

If you operate a name server hosting a DNSSEC enabled domain an attacker can easily send a ton of queries which are amplified by a factor of 10 to 15. A surprising number of DNS servers allows for amplification factor of 20 or more (we have seen a record amplification factor of 70 in one case). This can flood the DNS servers network link as much as it floods the victim of a DDoS attack.

Here is how rate limiting works: When a DNS client sends enough requests to trigger the rate limit, the server will no longer send the answers over UDP. Instead the server sets a flag indicating a “truncated response”.

This flag instructs the client to repeat the query over a TCP connection. Since this response is about the same size as the request it is not useful in a DDoS attack.

Example configuration for DNS rate limiting

Unfortunately, I did not find conclusive guidelines on the configuration of rate limiting. It is easy enough to activate, but which thresholds should I use? And after I have activated rate limiting, how do I know that it properly kicks in?

Yes, I know, that I can find rate limiting events in the log files. But I don’t want to wait for the next DDoS attempt to learn that my thresholds strike a proper balance between production traffic and DDoS prevention. And no, I don’t want to run a simple script that throws a ton of DNS requests at my server. I want a tool that is easy to use and shows the results in a comprehensible way. That’s why I created DNS Hammer.

One of my first targets was the Internet Systems Consortium. Most important for my case is the ISC’s widely used DNS Server BIND. An article in their knowledge base explains how to configure rate limiting, but won’t recommend specific values. Let’s use the DNS Hammer to find out how their servers are configured.

I pointed the tool towards the server ns1.isc.org and send a mix of 500 different requests. The following screenshot shows both the configuration for the test run and the result.

Out of my 500 requests per second only 200 received a result. The first 40 responses were given freely. Further responses came with the “truncated” flag. The server did not deny the request, but instead pushed the client to a TCP connection. You might have already assumed correctly that DNS Hammer will not follow up with a TCP connection.

One of the parameters in a DNS rate limiting configuration is “slip”. DNS recommends to set the value to 2, which causes the server to drop every other query. A quick overview over slip and the other parameters for rate limiting can be found in section 6 of ISC’s guideline on BIND Best Practices.

With a slip value of 2 we should receive 250 responses, since we send out 500 requests. It turns out, that ISC strongly advises to block queries for the ANY record. Here is another test run, where I am sending 500 queries per second, but this time not asking for ANY.

Now we get 250 responses as expected.

Summary

DNS reflection attacks are a nuisance. DNS servers can (and should) be configured to block excessive queries. This done through DNS rate limiting. DNS Hammer is a tool to audit the configuration.

The second part in this series will present the tool in greater detail.