Home / Blogs

Can We Really Blame DNSSEC for Larger-Volume DDoS attacks?

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?

By Andrei Robachevsky, Senior Technology Programme Manager at Internet Society

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC


Sponsored byDNIB.com

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API