DDoS on DNS root servers

Published
January 13, 2016
Type
What's Behind

On 30 November and 1 December, multiple Domain Name System (DNS) root servers faced a uniquely high requests rate, which saturated network connections close to several root servers, preventing valid queries from reaching them.

This sizeable traffic was a Distributed Denial of Service (DDoS) attack which had effects on several root servers all over the world.

Importance of DNS root servers

DNS is the internet service that translates easily-remembered names for servers and services into IP addresses, which ultimately allows a user to access that server or service. DNS works in a hierarchical manner. In order to determine the IP address of www.enisa.europa.eu and access this website, a machine needs to go through the following steps:

  1. Request a DNS root server for the IP address of the Top Level Domain (TLD) server responsible for .eu;
  2. Request the .eu DNS server for the IP address of the server responsible for europa.eu;
  3. Request the europa.eu DNS server for the IP address of the server responsible for enisa.europa.eu;
  4. Request the enisa.europa.eu DNS server for the IP address of www.enisa.europa.eu.

The results for the intermediate steps are cached, in order to limit the load on root servers and TLD servers. However, should the root servers be unavailable for a long period, caches would expire, and most of the internet would become unreachable. This makes the root servers one of the single most important resources on the internet.

Protection of the root servers

The DNS infrastructure was designed in a way that allows it to sustain huge loads. The following sections give an overview of the protection mechanisms that are currently in place.

Redundancy

The process above holds a kind of chicken-and-egg situation where it is not easy to determine which existed first and which caused the other. How can a machine know where the root servers are? There are 13 root servers, named "A" through "M". Every machine configured to use TCP/IP holds the list of the 13 IP addresses of these root servers. This is the first layer of protection: any of the 13 IP addresses can do the job, and there is no single point of failure.

More redundancy

While there are only 13 IP addresses, whole server farms hide behind most of these addresses. So even if one physical machine would be unavailable, others in the same server farm would reply to queries.

Anycast – Geographical redundancy

Usually, one IP address corresponds to one destination in a single physical location. For particular use cases, one IP address can correspond to several machines in different locations. This is called anycast, and requires the collaboration of the global routing infrastructure.

The use of anycast for DNS root servers allows the routing infrastructure to distribute requests to the many different servers, wherever they are in the world, and transparently for the user. For example, the IP address for the "F" root server (the 6th of the 13 root servers) actually corresponds to 50 different locations in the world (see Figure 1). This means that any DDoS attack against a service that uses anycast is automatically watered down. Some individual servers or network links may be saturated, but on the whole, the system will still work.

Locations for the "F" root server (source: ISC)

Figure 1 Locations for the "F" root server (source: ISC)

Significance of the attack

Use of IoTs

Researchers at Korea University analysed the effects of the attack on a root server in Korea. They traced the origin of the attack to infected home routers, internet-connected surveillance cameras, and television devices. It is the first time such devices are used on such a large scale.

This analysis was possible because the attack only involved straightforward requests, sent directly by the devices, as opposed to reflection and amplification attacks.

Magnitude

Despite the relative lack of visible effects, the attack was considerable. It is estimated that the root servers faced up to 250 times the usual number of requests, corresponding to about 320Mbps. This is not the biggest DDoS in history, but amplification techniques could easily have made the attack much worse. Protecting against an amplified attack would require more than anycast, and would require most ISPs to implement filtering of spoofed packets.

Motive

In our opinion, the attack was a demonstration of firepower by cyber criminals intending to sell DDoS-as-a-service. The evidence is of course circumstantial:

  • No amplification. If the goal of the attack was to actually prevent the internet from working, the attackers would have used easily-implemented amplification techniques. Instead, they chose to show raw firepower.
  • No public claim. The lack of public claim of the attack points to an underground actor rather than a nation-state or terrorist group, who would have most likely bragged about their capabilities or would have performed a full-fledged attack.

Conclusion

Thanks to its use of multiple redundancy layers, the DNS infrastructure can still work despite heavy attacks. Anycast is one of the most effective protections against DDoS attacks, but would not be enough to stop an amplified attack. The attack described in this document could have knocked down many services other than DNS, and could have been made much worse by using amplification mechanisms. Protection against an amplified attack would require ISPs to filter spoofed packets before they leave their infrastructure.

About "What's Behind" from ENISA

With the “What’s Behind” series ENISA aims at giving the interested reader some in-depth background about NIS related topics. The background is derived from past experiences and common sense; in no way should “What’s Behind” be understood as recommended course of action in a specific incident or investigation, or being a final conclusion. Feel free to get in touch with ENISA to discuss or inquire more information on the “What’s Behind” series (cert-relations@enisa.europa.eu).

We use cookies to ensure we give you the best browsing experience on our website. Find out more on how we use cookies and how you can change your settings.

Ok, I understand No, tell me more