Executive Summary: DNS has some limitations but there’s no reason for it to be the weakest link in your organization’s security. An incorrectly configured and neglected DNS server can be a significant security problem. DNS services, as providers of network information, will always be a target for reconnaissance and information gathering, but careful planning and vigilance will minimize the risk of malicious hackers using your own servers against you. There’s much you can do to build a solid and secure DNS infrastructure on your network, whether you're using Microsoft DNS or BIND.

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

If you use BIND, you can disable recursion by adding the following to the options section in named.conf:

Options {
  recursion no;
};

Note that with BIND, you can use an allowrecursion ACL to permit recursion only from trusted IP addresses. Although this might be the only possible solution in some configurations, the best protection is to prevent all recursion on public DNS servers.

Limit Zone Transfers
A surprisingly common DNS server mistake is allowing all hosts to perform zone transfers and allowing all records for a zone to be returned. Zone transfers let DNS servers share information, but you should be careful to limit which hosts can request them. If you don’t normally allow servers to update each other, you can completely disable zone transfers.

To limit zone transfers with Microsoft DNS, open the DNS Management Console, rightclick the domain you want to configure, click Properties, then access the Zone Transfers tab. If you want to enable zone transfers, be sure to allow only servers listed on the Name Servers tab or use specific IP addresses. Never allow zone transfers to all servers.

With BIND, you control this setting in named.conf. You can make the setting in either the global options section or individual zone sections. Keep in mind that settings in a zone section override that zone’s global options, so the best way to manage zone transfers is to prevent them globally, then configure individual zones to allow zone-transfer requests only from certain IP addresses. To do so, add to named.conf as follows:

Options {
  recursion no;
  fetch-glue no;
  allow-transfer { none; };
};

zone "example.com" in{
  ...
  allow-transfer
  ( 192.168.0.15; );
};

Reduce Exposure
To prevent abuse, it’s important to limit all network services to specific ports and IP addresses. You should always use a packet filter, such as a firewall or router, to limit access to your DNS servers, and you should configure limitations on the servers themselves. To configure Microsoft DNS to listen only on specific IP addresses, you can open the DNS Management Console, right-click the computer name, select Properties, and select the Interfaces tab. You can then enter specific IP addresses you want to listen on, as Figure 2 shows.

With BIND, you can set the listening IP address as a global option or a zone option in named.conf as follows:

Options {
  recursion no;
  fetch-glue no;
  allow-transfer { none; };
  listen-on {192.168.0.8; };
};

With Microsoft DNS, it’s possible to manage a remote DNS server using the remote procedure call (RPC) protocol. If you don’t use this feature, you should disable RPC to reduce your attack surface. To do so, you must edit the server’s registry. Using Regedit, locate HKEY_LOCAL_MACHINE\SYSTEM CurrentControlSet\Services\DNS\Parameters, and create a DWORD value named RpcProtocol. Set this value to 0, and restart the DNS server for the setting to take effect.

You Can Do More
At this point, your DNS server won’t allow recursive DNS requests from others, won’t attempt to answer queries outside its zones, will permit zone transfers only to trusted hosts, and will listen only on the IP addresses you specified. If it contains only public DNS records, the server is now secure enough to be a public DNS advertiser. With prudent firewall configuration, careful patch management, and other security best practices in place, you can be confident that your DNS server isn’t a threat to your network or others.

However, you can do more. Using IPsec between trusted hosts and implementing the DNS Security Extensions (DNSSEC) and Transaction Signature extensions can further increase the integrity and confidentiality of your DNS traffic. Careful server hardening will prevent other types of attacks on your DNS server. Finally, a good networkmonitoring system can warn you of impending attacks.