DNS Cookies and DDoS Attacks

DDoS attacks, particularly for ransom—essentially, “give me some bitcoin, or we’ll attack your server(s) and bring you down,” seem to be on the rise. While ransom attacks rarely actually materialize, the threat of DDoS overall is very large, and very large scale. Financial institutions, content providers, and others regularly consume tens of gigabits of attack traffic in the normal course of operation. What can be done about stopping, or at least slowing down, these attacks?

To answer, this question, we need to start with some better idea of some of the common mechanisms used to build a DDoS attack. It’s often not effective to simply take over a bunch of computers and send traffic from them at full speed; the users, and the user’s providers, will often notice machine sending large amounts of traffic in this way. Instead, what the attacker needs is some sort of public server that can (and will) act as an amplifier. Sending this intermediate server should cause the server to send an order of a magnitude more traffic towards the attack target. Ideally, the server, or set of servers, will have almost unlimited bandwidth, and bandwidth utilization characteristics that will make the attack appear as close to “normal operation” as possible.

It is at this point that DNS servers often enter the picture. There are thousands (if not tens of thousands) of DNS servers out there, they all have public facing DNS services ripe for exploitation, and they tend to be connected to large/fat pipes. What the attacker can do is send a steady stream of DNS queries that appear to be originating at the target towards the DNS server. The figure below illustrates the concept.

The attacker will carefully examine the DNS table, of course, choosing a large record—the largest TXT record possible is ideal—and send a request for this item, or a series of similar large items, asking the DNS server to send the response to the target. The DNS server, having no idea where the query actually originates, will normally reply with the information requested.

But one DNS server isn’t going to be enough. As shown in the illustration, the attacker can actually send queries to hundreds or thousands of DNS servers; an investment of ten to fifteen packets per second in queries can generate tens of thousands replies each second in return. To ramp the attack up, the attacker can install software (probably through a botnet) that can use hundreds or thousands of hosts to generate packets towards thousands of DNS servers—this kind of amplification can easily overwhelm even the largest edge circuits available.

How can this sort of attack be countered? The key point is to remove amplification wherever possible—in this case, DNS servers seem like a likely point at which the amplification attack can be cut down to size. But how? RFC7873, DNS Cookies, published in May of 2016, provides a weak authentication mechanism to reduce the effectiveness of DNS as an amplification platform.

Essentially, this RFC specifies that each DNS query should include a cookie, or what might be called a nonce. This cookie is calculated using a consistent algorithm (a hash) computed based on several items, such as the IP address of the client (sender), the IP address of the server, etc. The idea is this: the first time a host queries a DNS server, it will send a client cookie. The server can respond with an error, simply ignore the request, or respond with a DNS packet containing the server’s cookie. The rate at which the server hands the cookies out can be rather limited; assuming clients can cache the server’s cookie as well as previous DNS records retrieved from the server, the additional rate limiting should have very little impact on the host’s operation. The next time the client sends a request, it will include this server cookie. The server, on seeing a valid cookie, will reply to the request as normal.

The figure below illustrates.

This process accomplishes two things:

• Rate limiting responses to “cookie requests” effectively caps the speed at which any given client can send packets with a forged source address to the server and expect a reply. It doesn’t matter how fast the attacker sends packets, it will only receive a cookie making it possible to send a valid request on an infrequent basis.
• Given the attacker will not be able to successfully forge a cookie for the target, the only thing the attacker can force the DNS server to send to the target is a (purposefully) short error message. These error messages will have nowhere near the impact of the carefully chosen large TXT (and other) records.

This is, as the draft says, a “weak protection,” but it is enough to remove DNS servers out of the realm of “easy targets” for amplification duty in DDoS attacks.