In its security bulletin, Akamai’s Security Intelligence Response Team (SIRT) reported on abuse of DNS Security Extensions (DNSSEC) when mounting a volumetric reflection-amplification attack. This is not news, but I’ll use this opportunity to talk a bit about whether there is a trade-off between the increased security provided by DNSSEC and increased size of DNS responses that can be leveraged by the attackers.

Let’s look at the issue more carefully.

DNSSEC provides a level of additional security that allows the client to cryptographically check that the received answer is exactly the same as published by the domain owner and wasn’t modified in transit. When using DNSSEC-enabled queries for DNSSEC-protected domain names, the responses contain additional information—signatures and cryptographic keys—used to validate the answers. But DNSSEC is only part of the amplification story.

When DNS was devised, the maximum response size over UDP was fixed at 512 bytes. It was too small to efficiently support the additional information that can be conveyed in the DNS with the advent of new applications (e.g., IPv6 or DNSSEC signatures). To resolve this, in came Extension Mechanisms for DNS (EDNS0) in 1999 (RFC 2671), which was updated and obsoleted by RFC 6891 in 2013. This allowed the payload to be as large as needed to fit in the maximum UDP packet size of 64KB. For practical reasons, the limit is 4KB and to avoid fragmentation DNS servers commonly set the maximum response size of 1472 bytes for IPv4 and 1232 bytes for IPv6. So, given a query size of 40 bytes, a theoretically achievable amplification is 102.4 times.

Of course, DNSSEC helps to fill up such a response, but there are other possibilities, especially if an attack is using specially crafted records (TXT, multiple AAAA or A records).

Another issue is there is no shortage of amplifiers beyond DNS. Take SSDP, SNMP, NTP, and in some cases any TCP server can be a reflector (some TCP implementations can also send significant amounts of data as part of the first response).

So, when talking about reflection-amplification DDoS attacks, we need to look at the real culprits:

• Systems generating traffic with spoofed IP addresses and networks allowing such traffic. This is, in fact, a root cause of reflection attacks, although the one that is nearly impossible to track back currently. Many such systems together are operated as a botnet.
• Reflectors and Amplifiers: remote applications that will respond to requests coming from compromised hosts. These responses will be directed at the target specified by the spoofed source IP address in the requests.

There are various strategies that can be applied to mitigate a DDoS attack. Many of them—like preventing source IP spoofing in a network, closing an open resolver, or rate limiting—produce a long-term sustainable effect that reduces probability and impact of such attacks. But there are also challenges, as it requires many parties to work together in addressing these issues. I wrote about this on CircleID last year in, “Can We Stop IP Spoofing? A New Whitepaper Explores the Issues.”

Can you do your part to prevent DDoS attacks? And if you are willing to do your part, how about signing on to the Mutually Agreed Norms for Routing Security (MANRS) initiative and joining with other members of the industry to make a more secure Internet?