Collaboration

Detect and mitigate a DDoS attack against your DNS server

John Joyner recently observed a real-world DDoS attack against an on-site DNS server. Here's how you can protect yourself against these types of attacks or at least mitigate the threat.

If you host the Domain Name Service (DNS) on your own servers, you need to be aware of the very real threat of a Distributed Denial of Service (DDoS) attack. If your DNS service is subject to a DDoS attack, you can expect, at minimum, a loss of email and web server services. If your DNS host is located on- premises, sharing the Internet connection of your users' web browsing activity, a DDoS attack is equivalent to a complete loss of Internet service to your organization. This could be true even if the DNS service you expose to the Internet is just for testing or other limited purposes.

The rise of this threat means DNS can join File Transfer Protocol (FTP) as a service that you should generally not publish to the Internet directly from your premises. Many administrators know that as soon as you put an FTP server on the Internet, hackers and bots will start hammering away with brute force methods such as user name and password guessing. Even if you have complex passwords or passphrases in use, just the volume of failed FTP accesses can overwhelm networking resources.

A take-away is that there is some degree of hazard involved in hosting your own DNS. In other words, this is a big endorsement of hosted DNS services, and a suggestion that most everyone consider trusting an Internet Service Provider (ISP) or other hosting professional for your DNS publishing if you are not already doing so.

What does a DNS DDoS attack feel like?

A recent experience with an actual attack was the inspiration for this article. The "victim" in this scenario is a small office in North America with a DSL router and a static Internet IP address. An on-premise server publishes public DNS records directly to the Internet. Early indications of something wrong were (1) reduced inbound Internet email volume and (2) slow web browsing. After a couple of days of reduced functionality, the location experienced a stoppage of inbound Internet email, and you could not surf the web any longer. "Ping" requests to Internet hosts either failed or had over a 1,000 millisecond (ms) response time, basically an unusable connection.

Obviously some process was flooding the DSL Internet connection. Each PC in the office was restarted without an effect. Restarting the DSL router also had no effect. However, restarting the server did restore a fast Internet connection for a short while. After a few minutes of a clean connection, quickly the Internet connection became unusable again. Suspecting an email or web-based process was the culprit, Exchange and web services were stopped on the server to no effect. Through trial and error, stopping the DNS Server service produced immediate relief and isolated the issue to the local DNS service.

There were no warning events in the DNS Server service log, and the server itself was confirmed to have all current updates installed, in particular all updates involving the DNS service and DoS exploits. The next place to look for clues was the firewall. Although the firewall did not have a historical logging feature, you could enable a real-time log for selected protocols. Live log review for DNS traffic through the firewall showed that there were two Internet IP addresses sending continuous DNS traffic to the local server. The two servers were located overseas, in different European countries, both sending the flood of traffic to the same local DNS server. The fact that there were two or more simultaneous remote sources of the directed traffic classifies the attack as a Distributed DoS.

Protecting against DNS DDoS

Once you know the IP addresses of the offenders, it is a simple matter to put rules in your firewall that block traffic from those addresses. Blocking the first IP address reduced "ping" response time to about 300ms. Blocking the second IP reduced response time to a nominal 30ms and all service was restored. This small office was fortunate that its DNS service was only being attacked from two sites with static addresses. If the attack had been from dozens or hundreds of sources (or if the source IP addresses were changing), the small office might have had a more serious and business-impacting problem.

As mentioned at the top of this article, the best defense is to move any DNS services to a DNS service provider, such as your ISP, DNS registrar, or another hosting professional. While this won't eliminate the threat of DoS against your DNS records at the service provider, it will remove the threat of a DoS attack also impacting your on-premise users' ability to surf the web. To directly reduce the threat of any DoS impacting your business, consider a package like AT&T offers its enterprise customers: Denial of Service - DDoS Protection.

If you must host your own DNS for whatever reasons, you need to plan for defense against DNS DoS, such as deploying multiple DNS servers at different sites and/or using hardened and dedicated DNS servers or appliances with their own Internet connections. Verisign released a State of DNS Availability Report in May 2011, confirming that DNS availability was a problem for even the top ranked e-commerce sites, and was especially difficult to manage for organizations that host their own DNS service.

Also read:

ZDNet: Russian Embassy in London hit by a DDoS attack

About

John Joyner, MCSE, CMSP, MVP Cloud and Datacenter Management, is senior architect at ClearPointe, a cloud provider of systems management services. He is co-author of the "System Center Operations Manager: Unleashed" book series from Sams Publishing, ...

5 comments
Phillip H Kim
Phillip H Kim

Hi , John Thanks for your good article , and I attached my experience and thought , In case small corp , if they run DNS by themselves , The best way is MAXIMIZE TTL that could be copied to numerous ISP's Name Server Normarlly DDoS Uttack is under 3hour in one time , So I strongly recommend TTL above 3hour .

AnsuGisalas
AnsuGisalas

In DDOS attacks, the bots may use an exposed server with unfortunate settings to attack a different target. They send forged incomplete packages to the "first in line target", which then sends queries to the real target for the attack. That means that the people doing forensics at the first line target actually think the real target(s) was attacking them, while it was really the other way around - and the sender of the forged packages can be any number of members of a botnet. The best way to prevent this is to have the server automagically drop all incomplete packages, and never query a sender that it's not necessary to query. Saves both targets. I refer to gibson research on a more correct, complete and accurate account. That's where I read the above, some six years ago. Also at GRC they have a DNS tester which checks DNS'es for bad habits. OpenDNS for example has a bad habit of forwarding queries that don't fit a target to an ad-riddled disambiguation service. A DNS should simply drop such requests (also), as bleeding information around the place is no good for anybody, except the bad guys.

John Joyner
John Joyner

Hi Michael - The server was providing public DNS services for a public DNS zone. Not a best practice but not uncommon for small, lab, and test environments. In this case the environment had run in this configuration for years with no issues. No review of the content of the traffic was done, it was just isolated to port 53. There was no unusual security, system, or DNS events so it is likely it was all query traffic. - John

Michael Kassner
Michael Kassner

Why was the DNS server facing the Internet and not just servicing the internal clients? Also, what was the DDoS traffic -- DNS queries?