Securing DNS Servers - Part 1

Without a doubt, the most critical infrastructure component on the Internet is DNS. Every other service, including e-mail, depends on it. Yet, surprisingly enough, a large percentage of DNS servers have yet to be secured. In this first of a two part posting, I’ll describe some of the issues surrounding DNS servers. Next week’s post will include steps you can take to secure your servers.

Outside of the usual implementation specific security bugs, there are four main reasons to improve the security of your Internet facing name servers:

1. Spoofing

Over time various methodologies of spoofing DNS results have surfaced using a technique called cache poisoning. This takes advantage of the DNS server’s desire to cache answers for future use in order to cut down on network traffic and reply latency. Initially this was done by providing poisoned data in the additional information returned with a legitimate reply. Lately, these attacks have tried to take advantage of weaknesses in the DNS protocol to poison the DNS server. To read more about cache poisoning and the techniques involved, I recommend the Illustrated Guide to the Kaminsky DNS Vulnerability.

2. Denial of service attacks

A popular method of performing a denial of service attack is by attacking name servers. If a user can’t translate www.google.com to an IP address, they can’t reach the Google web site. A popular technique to knock off a target server is a DNS amplification attack, in which an attacker uses a set of DNS servers which are configured to respond to all recursive queries (regardless of source). In the attack, a relative small query is broadcast with a spoofed sender IP address belonging to the intended victim. Those recursive servers then reply to the victim with a much larger (amplified) response packet. By employing enough recursive servers, the victim, and at times, the recursive servers themselves, are flooded with DNS packets to be processed. For more information on this type of attack, refer to the DNS Amplification Attacks paper by Randal Vaughn and Gadi Evron.

3. Information leakage

For the most part, DNS operates by answering specific questions with specific replies. However, to support synchronizing redundant secondary servers, most DNS servers also allow for a domain’s entire zone to be transferred to the secondary server. However, unless specifically protected, zone transfers are open to any host requesting the information. Typically, a zone file contains all of the publicly available hosts for your site and can be a wealth of information for an attacker.

4. Theft of service

As mentioned in the denial of service attacks section, name servers can be configured to answer recursive queries for any host on the Internet. Even if not used maliciously in attacks, this allows anyone to use your name server for handling DNS client resolution. This is much like promiscuous relaying in e-mail that was common back before spammers arrived on the scene. While it is nice to offer your services to the Internet at large, this can often lead to abuse and the burden of responsibility for the actions of others.

Next week, we will look at steps you can take to protect your servers. In the mean time, your homework assignment is to prepare by determining which hosts should be allowed to use your name server for recursive name resolution (i.e., as a DNS client), and, secondly, for each zone you publish on the Internet, which hosts should be allowed to perform a transfer of the zone (i.e., who are the secondaries for the domain).