Home / Blogs

Verisign's Perspective on Recent Root Server Attacks

Duane Wessels

On Nov. 30 and Dec. 1, 2015, some of the Internet's Domain Name System (DNS) root name servers received large amounts of anomalous traffic. Last week the root server operators published a report on the incident. In the interest of further transparency, I'd like to take this opportunity to share Verisign's perspective, including how we identify, handle and react, as necessary, to events such as this.

From time-to-time, the DNS root name servers receive traffic that, in theory, they shouldn't. Some examples of this are: (1) the constant level of "DNS background radiation" in the form of names with non-existent top-level domains (i.e., names that do not exist in the global Internet DNS ecosystem), (2) address lookups for strings which are already well-formatted IP addresses, and (3) repeated queries for the same name. I was involved with some research assessing the frequency and implications of this a dozen or so years ago, available at Wow that's a lot of packets! Another example of traffic that shouldn't be observable at the root is the occasional presence of large query volumes that we generally and unfortunately consider to be "attack traffic."

Sometimes, the DNS root name servers receive attack traffic where the intent seems to be clear. By examining the traffic, and perhaps with other supporting information, it may be easy to discern whether the intended victim is a third party, or perhaps the root server system itself. At other times, however, the intent is less obvious.

Intent of the Attack Unclear

The events of Nov. 30 and Dec. 1, 2015, are one of those cases where the intent as observable on the root server operations side of the system is unclear. While a number of DNS root name servers did receive high levels of traffic, it is unclear whether the intent was to harm the root server system itself.

In analyzing these types of events, we often try to look at where the traffic is coming from. We seek answers to questions such as:

  • Are the sources spoofed, or not?
  • Is it hitting one anycast site, or many?
  • Do the packets come from a small number of machines, or a widely distributed botnet?
  • To what extent does the anomalous traffic deviate from normal for the systems involved?

It likely comes as no surprise that in the attack events we see, the source addresses are usually spoofed, as there is typically little motive or objective in attacking the root server system itself. That is certainly true for the most recent events from our perspective.

To provide a bit of background, in addition to our role as the Root Zone Maintainer, Verisign also operates the A- and J-roots. Verisign and many other root server operators use IP anycast to provision sufficient capacity, minimize transaction latency, and to serve geographically and topologically diverse end users all over the world. For example, while Verisign has headquarters in the U.S., we have both business and technical operations globally. We operate over one hundred A- and J-root sites that are spread throughout the world as illustrated in the map below.

A-root sites shown in red. J-root sites shown in green. (Click to Enlarge)

Our globally distributed root, the .com and .net domains, and other DNS resolution service platforms gives us the ability to absorb large-scale traffic events such as flash crowds or distributed denial of service (DDoS) attacks, while preserving consumer services availability and minimizing transaction latency. Our diverse footprint also aims to balance density of nodes globally with geographic and aggregate transaction servicing capacity and resiliency in the event of incidents such as trans-oceanic cable cuts, natural disasters or other large-scale events.

In the case of the root server system, the diversity in operational practices and capabilities across the 12 root server operators (i.e., Verisign and the 11 others), coupled with the resiliency and failover capabilities inherent in the DNS architecture itself, afford diversity and availability preserving measures when component issues arise. For more information on the root server operators, including the locations of all instances, please visit www.root-servers.org.

With that background, let's return to discussion of the recent incidents. The video embedded here is a visualization of a subset of the Nov. 30 traffic anomalies received by A-root and clearly demonstrates (1) that source addresses are spoofed, and (2) packets and sources are probably generated by multiple processes, systems or algorithms. The traffic received at J-root is essentially identical.

Classification & Mitigation

In addition to anycasting and an array of DNS transaction processing capabilities, Verisign and the other DNS root server operators have a number of techniques for identifying anomalous system loads and then classifying and mitigating malicious activity, as appropriate.

One simple, "always on" technique is the blocking of packets that appear to come from so-called bogon address space. More generally, these are called Special Use Addresses, and are catalogued in RFC 5735. At Verisign, depending on the site architecture, we typically drop packets with a bogus source address on ingress at our border routers so they never reach our servers. Looking at the visualization, it's easily observable that no queries were received from 0.0.0.0/8, 10.0.0.0/8, and 127.0.0.0/8, while all of the surrounding address blocks did receive those queries.

Source address filtering is another mitigation technique commonly utilized to squelch attacks of this sort, although not usable at the root server system itself in this case due to the obvious presence of source address spoofing employed by the attacker source networks (i.e., hundreds of millions of spoofed source addresses). Attacks such as this can only originate from networks that fail to validate source addresses. Various Internet groups, such as the Internet Engineering Task Force (IETF) and the Internet Corporation for Assigned Names and Numbers (ICANN), have been urging network operators to employ ingress filtering and source address validation for many years. The oft-referenced BCP38 document was written 15 years ago. The ICANN Security and Stability Advisory Committee (SSAC) has written a number of documents on the topic of DNS-based attacks, including SAC004, SAC005, and more recently, SAC065. The so-called Smurf attack and other spoof-based attacks have remained both popular and effective over the last two decades.

Incidents such as this one can also be mitigated with the response rate limiting technique (RRL). The general idea is to ignore some queries where the response would be a repeat of a previous response to the same address or group of addresses. RRL can work well, but does introduce the risk of blocking responses to legitimate queries. Should a legitimate query be blocked, the DNS client (i.e., a recursive name server) should retry, possibly at a different server. The RRL design also includes a feature to let some potentially blocked responses "slip" through and return them with the DNS truncation flag set, thus encouraging the client to retry over Transmission Control Protocol (TCP).

Depending on the attack vector, an array of other techniques can be used to mitigate these and other types of DDoS attacks, all with the aim of minimizing any collateral damage and preserving service availability for all Internet users.

By Duane Wessels, Principal Research Scientist at Verisign

Related topics: Cyberattack, Cybersecurity, DDoS, DNS, Networks

 
   

Don't miss a thing – get the Weekly Wrap delivered to your inbox.

Comments

Enjoyed reading this. Chris Buijs  –  Dec 29, 2015 6:35 AM PDT

Thanks for the clear article, interesting read!

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper

Verisign

Cybersecurity

Sponsored by Verisign
Afilias

DNS Security

Sponsored by Afilias
Afilias Mobile & Web Services

Mobile Internet

Sponsored by Afilias Mobile & Web Services

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Industry Updates – Sponsored Posts

Verisign Named to the Online Trust Alliance's 2017 Audit and Honor Roll

Attacks Decrease by 23 Precent in 1st Quarter While Peak Attack Sizes Increase: DDoS Trends Report

Leading Internet Associations Strengthen Cooperation

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Don't Gamble With Your DNS

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Facilitating a Trusted Web Space for Financial Service Professionals

MarkMonitor Partners with CYREN to Deepen Visibility into Global Phishing Attacks

Verisign Named to the Online Trust Alliance's 2016 Honor Roll