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.