‹ Back
Deploy360 22 February 2016

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

Andrei Robachevsky
By Andrei RobachevskySenior Director, Technology Programmes

DNSSEC badgeIn 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 4K 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 can be 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?

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Microsoft Security TechCenter: DNSSEC and DNS Amplification Attacks
Deploy36025 April 2012

Microsoft Security TechCenter: DNSSEC and DNS Amplification Attacks

What are the security risks related to using DNSSEC with regard to "DNS amplification attacks"? In a recent article at...

DNS Security & Privacy discussed at e-AGE18
DNS Security & Privacy discussed at e-AGE18
Deploy36024 December 2018

DNS Security & Privacy discussed at e-AGE18

The Internet Society continued its engagement with Middle East networking community by participating in the e-AGE18 Conference, where we took...

Excellent DNSSEC Sessions Coming Up At DNS-OARC Spring Forum This Weekend
Deploy3609 May 2013

Excellent DNSSEC Sessions Coming Up At DNS-OARC Spring Forum This Weekend

This weekend begins the "Spring Forum" of the Domain Name System Operations Analysis and Research Center, a.k.a. "DNS-OARC" and it...

Join the conversation with Internet Society members around the world