How we can get out of the DNS DDoS trap

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

A new class of enormous DDoS attacks emerged March 26 with a DNS reflection attack by email spammer CyberBunker against anti-spam service Spamhaus. The reported traffic peak of 300Gbps was double the previous record.

Experts say these enormous volumetric attacks will gain in popularity due to the fact they leverage existing Internet DNS servers, meaning there is no need to recruit one's own botnet or even rent one. These types of attacks are called reflection (and sometimes amplification) attacks because a relatively few, small requests directed at a DNS server result in a significantly higher amount of response traffic that is forwarded towards the victim.

[ IN THE NEWS:Possibly related DDoS attacks cause DNS hosting outages

ROUNDUP:The year's worst data breaches (so far)]

The good news is this type of systemic problem has been faced before, and to some extent, fixed. Remember when email spam was the majority of Internet traffic? DNS reflection attacks are a similar problem, though, thank goodness, there isn't the same insane direct profit motive that drove email spam.

What enables DNS reflection attacks is the continued tolerance of open DNS resolvers on the Internet. A DNS server is considered to be an "open" resolver if it will accept and forward name queries for domains that it does not serve. These open resolvers can then be used in this way to generate the traffic load against the victim. Typically a resolver does not need be open -- it is usually just misconfiguration that causes this and the owner/operation doesn't even know it is happening. The Open Resolver Project lists 25 million of these servers. If they were considered a botnet, it would be among the largest and most powerful botnets ever created.

Another aspect that enforces the status quo and enables DNS reflection attacks is the devotion to the minimization of latency. Everyone wants the Internet to be fast (who wouldn't?), and a responsive DNS system is seen as key. The very, very large DNS systems deployed by carriers can and do regularly respond to millions of queries per second. Single-packet requests and responses via UDP are used to achieve this scale. But the stateless nature of UDP means that it does not provide identity and is effectively "untraceable" -- attackers can very easily spoof UDP packets and the DNS servers have no way to tell that this has been done and that by responding they may be unwittingly attacking an innocent victim.

So, is there a way out of this DNS DDoS trap?

A smarter DNS infrastructure is the answer; a smarter infrastructure that is mindful about not just its positive impact but also its destructive ability. Enterprises, vendors and services can work together to bring the DNS infrastructure to this higher plane of intelligence.

Vendors need to make smarter DNS products. The current defensive techniques, such as ignoring the first lookup request, are crude and aren't solving the reflection problem. The new class of DNS servers must be aware of attacks and rate-limit their responses in pathological situations.

One idea whose time might have come is to detect attack conditions and then redirect incoming queries to use TCP for the duration of the attack. This may result in higher latency (due to TCP overhead) and mean some servers will need to be upgraded since many Internet DNS servers will suffer a significant performance penalty during TCP, but its effect should be temporary (just the duration of an attack).

But enterprises should also tighten their configurations to prevent the kind of amplification requests that caused the March 26 attack. Specifically, there is very little reason a server should respond with an entire zone dump except to specifically whitelisted addresses. Enterprises can also block the requests of the "any" record type, for which there aren't many common uses anyway.

One of the contributing factors that have helped mitigate email spam (itself a volumetric attack) was the existence of blacklisting services (such as a Spamhaus; there is irony here). Spamhaus monitored the Internet for open mail relays and advertised that intelligence as a service -- enterprises used the Spamhaus lists to automatically block spam. For DNS, there are severalfreeservices that monitor the millions open DNS relays on the Internet.

So far, the only method attempted to close the 25 million open resolvers is mild public shaming via these public lists. Clearly, though, showing up on this list isn't enough, and in fact, publishing the list is like handing out the addresses of a giant botnet to anyone who wants to use it! Since shame isn't working, perhaps the time has come for more extreme measures. Moving forward, if "good" DNS servers stop responding to the blacklisted open resolvers, this may force the indolent to clean up their acts, just as services such as Spamhaus have done for email.

The conflict between CyberBunker and Spamhaus may be over -- the individual attacker was recently arrested (after being shown to have launched his attack from his own high-tech van). However, unless the industry builds a smarter DNS infrastructure, the DDoS war with DNS reflection attacks may just be starting.

F5 helps organizations meet the demands and embrace the opportunities that come with the relentless growth of voice, data, and video traffic, mobile workers, and applications -- in the data center, the network, and the cloud. The world's largest businesses, service providers, government entities, and consumer brands rely on F5's intelligent services framework to deliver and protect their applications and services while ensuring people stay connected. Learn more at

Read more about wide area network in Network World's Wide Area Network section.

Join the CSO newsletter!

Error: Please check your email address.

Tags whitelistingSpamhaus attackSpamhausopen DNSDNS DDoSopen DNS resolverscybercrimeblacklistingDNS amplificationsecurityddosCyberBunkeropen resolver projectlegalDNS reflection

More about F5

Show Comments