Secure Your DNS Servers

The DNS protocol is peculiar. It’s one of the oldest, most universally used, and most crucial of all networking protocols, but it’s still the source of many network security problems. DNS has some fundamental limitations, but there’s no reason for it to be the weakest link in your organization’s security.

Perhaps it’s DNS’s apparent simplicity that breeds complacency toward DNS security. It’s easy to set up a DNS server and forget about it, but an incorrectly configured and neglected DNS server can be a significant security problem. DNS services, as providers of network information, will always be targets for reconnaissance and information gathering, but careful planning and vigilance will minimize the risk of malicious hackers using your own servers against you. You can do much to build a solid and secure DNS infrastructure on your network, whether you're using Microsoft DNS or BIND. (For information about the security differences between BIND and Microsoft DNS, see the sidebar “Microsoft DNS vs. BIND.” )

DNS Server Attacks
To secure a DNS server, you need to understand how others might exploit it. The most common threats are Denial of Service (DoS) attacks, tampering with DNS records, and information gathering. DoS attacks are probably the most common threat because they’re remarkably easy to pull off, thanks to the large number of incorrectly configured DNS servers on the Internet. DNS servers are often the launching points for DoS attacks, wherein an attacker uses a DNS server that allows recursion to pummel another server with packets. This kind of attack starves the target server of resources and prevents legitimate users from accessing it.

DNS tampering, which takes several forms, is less common but still a threat. One common method of DNS tampering is cache poisoning, in which an attacker injects fake records into a DNS server’s cache. Other methods of modifying DNS records include forged packets, man-in-the-middle attacks, and rogue DNS servers. In addition to modifying records, attackers use DNS servers for information gathering through DNS server mining, zone transfers, and DNS packet interception. Properly configured DNS servers can greatly limit your exposure to all these tactics.

Isolate DNS Functions
The first step to preventing attacks on DNS servers is to plan your network infrastructure so that you isolate DNS server functions. The term DNS server describes two very different functions—a fact that can lead to confusion during configuration. A DNS server can be an advertiser of information, or it can be a gatherer (resolver) of information stored elsewhere. To maximize security, it should never perform both functions simultaneously.

Your DNS advertiser stores and publishes authoritative records about a domain that you control. The DNS advertiser could be a public DNS server, which tells outsiders how to reach your website or mail servers, or an internal Active Directory DNS server, which tells clients where to find resources such as domain controllers. In contrast, your DNS resolver accepts DNS requests from within your organization and contacts outside DNS servers as necessary to locate host information. DNS resolvers can cache records to speed up future lookups and can act as forwarders to redirect client lookups to different DNS servers.

Most DNS servers work fine performing both functions at once, and organizations commonly have several DNS servers that perform both. This practice, however, is the primary reason so many DNS servers are vulnerable. You should have at least three distinct server roles on your network: Internet-facing DNS advertisers for publicly available servers, private DNS advertisers for AD and other internal DNS records, and DNS resolvers to perform lookups, caching, and forwarding for internal clients.

You should split these roles to improve performance and limit exposure to cache poisoning and DoS attacks. To further mitigate DoS attacks, you should have at least two servers in each role. Although many companies use a single DNS server for all roles, isolating server roles is always the best practice, because even if a configuration is not vulnerable now, it could become vulnerable in the future.

Carefully securing all DNS server roles is important, but I want to focus on the most crucial role: the Internet-facing advertisers.

Public DNS Advertisers
Your Internet-facing DNS advertisers are the only DNS servers visible outside your network, so you need to limit the information stored on them; otherwise, attackers might exploit them. Public advertisers should hold only public host records and should publish records only for servers accessible from the Internet—for example, web, mail, and FTP servers. Public advertisers should contain only public IP addresses and other public records such as Sender Policy Framework records and basic contact information. If any of your network adaptors point to your public DNS servers, chances are you have a problem to fix.

Although controlling information is important, your primary strategy for securing public advertisers should be to make sure they respond only to requests for the records they hold. They should never perform DNS lookups or look up other information on behalf of someone requesting records. Limiting responses will eliminate cache poisoning and prevent others from using your DNS server as a reflector in a DoS attack. Several steps are necessary in both BIND and Microsoft DNS to secure public advertisers.

Disable Recursion
Recursion allows a DNS server to track down a host record on behalf of another server. The problem with recursion is that in the process of performing lookups for others, a DNS server might be vulnerable to cache poisoning. Furthermore, attackers often use recursive DNS servers as part of a distributed DoS attack.

Attackers perform DoS attacks by creating large DNS records on servers that they control, then sending thousands of requests to recursive DNS servers all over the Internet. The requests are spoofed to look as if they come from a single IP address, so each DNS server will grab the record, cache it, and return it to the spoofed IP address. By repeating this process, the attacker can flood a target server with packets. The only way to prevent the flood would be to configure every public DNS server on the Internet to block recursive queries. Fixing the estimated half-million DNS servers that allow recursion is impossible, but you can do your part by fixing your own servers.

To disable recursion with Microsoft DNS, open the DNS Management Console, rightclick the computer name in the left pane, and select Properties. Click the Advanced tab and select the Disable recursion check box, as Figure 1 shows. Also, confirm that the Secure cache against pollution option is selected.

Continue to page 2