DNS Lockdown

When planning the 1941 attack on Pearl Harbor, the Japanese Imperial Navy targeted three key US resources. Most people know that the first was the fleet of US battleships, which was decimated in the attack. The second, equally well known, was the US aircraft carrier fleet, which was safely at sea far from Hawaii on December 7. Less widely known was the third target: more than 4 million barrels of fuel oil stored at Hawaii, which the Japanese thought might be the most crucial target but were unable to find. Despite the devastation of the attack on Pearl Harbor, the attack was a failure in two of its three strategic objectives.

Like battleships and aircraft carriers, mainframes and servers receive most of the attention from experts who analyze security risks for a private network. Yet a network's "oil" might actually be the infrastructure functions, such as DNS, that keep it running.

DNS: At Risk?
Because DNS neither stores nor transmits proprietary data, it might seem an unattractive target for attackers. But DNS can attract several types of attacks—for example, someone could intercept DNS registrations and use them to impersonate users.

DNS deserves protection because its functionality is vital and the data it stores is valuable. In terms of functionality, DNS makes an appealing target, if only for Denial of Service (DoS) attacks. Anyone who has experienced a complete DNS failure realizes that it can be crippling. And the data that DNS stores is valuable, especially to malicious intruders. DNS zone files often contain the names and addresses of network routers, servers, and mainframe hosts; the name of virtually every system; and even alias (i.e., Canonical Name—CNAME) resource records that are used specifically for applications. Although ignorance of system names or IP addresses might not stop intruders, it can delay them, sometimes long enough to be detected.

Microsoft, at least since the introduction of Windows 2000, seems aware of the importance of DNS security. Making just six changes in your network security will bring your Windows DNS server defenses up to speed.

Step 1: Set Up DNS Zones for Internal and External Use
The first step in ensuring that DNS doesn't become a security liability begins when you select zone names. Many organizations chose their domain name long ago, and changing it (and any code that relies on it) would be time-consuming and expensive. If that's the case, so be it.

But if you're designing a new implementation, be aware that the best philosophy is to never willingly give out information, no matter how unimportant it might seem. Most organizations use the same name (e.g., mightymouse.com) both internally and externally. Using the same DNS domain name inside and outside your network means that everyone who sees an employee's email address knows part of the name of all your internal servers. But if you use mightymouse.com on the Internet and mm.com internally, you place one more protective barrier around your systems. Using one zone name for your external (public Internet) presence and another zone name internally—especially behind your firewall—isn't difficult and costs nothing.

Step 2: Upgrade to Win2K DNS
Windows Server 2003, Win2K Server, and Windows NT Server all include DNS. However, all versions of DNS aren't equally secure.

Before the release of Win2K, you could network Windows systems with or without DNS (although some centralized name resolution system, such as DNS or WINS, was a de facto requirement for large routed environments). With NT 4.0, Microsoft included a simple DNS implementation based on BIND 4.9.8. NT DNS provides a stable, functional name resolution service, but one that provides no ability to minimize DNS communication risks.

Deployment of Win2K's Active Directory (AD) requires support of DNS servers. Those servers don't need to run on Win2K, but they must be compatible with BIND 5.4 or later. Win2K's own DNS jumps to BIND 8.2.3 and, compared with NT DNS, offers several security enhancements, including secure zone transfers and secure updates (with Microsoft clients). If you're running DNS on an NT server, you should upgrade that server to Win2K if possible.

Step 3: Structure DNS for AD Integration
Win2K DNS lets you configure zones as either standard or AD-integrated. Standard zones are the same as those available with NT: They store DNS information in a plaintext file, share zone information among DNS servers through a manually configured unencrypted transfer process, and transmit client record updates without encryption across the network. In AD-integrated zones, DNS information is stored with encrypted directory information and transferred between servers as part of the AD replication process, which encrypts data during transmission. AD-integrated zones also let you secure data that clients send to the DNS server during record updates.

Clearly, AD-integrated zones are the superior choice, but using them requires you to do more planning when deploying servers to host DNS. The two key requirements are that DNS must run on domain controllers (DCs), and those DCs must all be in the same domain. These requirements might not be easy to accommodate. If an organization uses the same domain name internally and externally but segregates its servers into many domains, placing DNS servers in all physical locations (to improve name resolution performance) might require deploying additional DCs for a domain even though the domain might not be used in some of those locations. Adding bandwidth for passing otherwise unnecessary domain replication traffic could further increase that expense.

A DNS implementation doesn't need to be purely AD-integrated. Several DCs can host the zone (and serve as targets for clients' secure updates) in AD-integrated mode. You can configure as secondary DNS servers other servers that aren't DCs or that aren't within the hosting domain, and those servers can provide local name resolution for clients. Be aware, however, that transfers from an AD-integrated zone to a standard secondary DNS server aren't encrypted.

To create a new AD-integrated zone, follow these steps:

To convert a standard DNS zone to an AD-integrated zone, follow these steps:

Step 4: Set NTFS Security for Standard Zone Files
Whether you run DNS on Win2K or NT, you should take the precaution of using NTFS file security. Because the DNS service stores AD-integrated zones in the AD database, not as a file, NTFS permissions don't affect them.

AD-integrated zones aren't available with NT, and some Win2K installations must use standard zones to maintain compatibility with downlevel DNS servers. Standard zones are stored as plaintext files with a .dns extension in %systemroot%system32dns, usually on the C drive. So, a standard zone named joe.com would typically reside in C:winntsystem32dnsjoe.com.dns. You should store these files on an NTFS partition and grant Full Control only to domain Administrators, as Figure 2 shows.

NTFS permissions protect the contents of a standard DNS zone from several types of unauthorized access, including access through network shares and FTP and direct physical access to the server. NTFS permissions also protect data in standard zone files from interception by packet-analysis programs and sniffer hardware during record updates and zone transfers.

Step 5: Secure DNS Zone Transfers
DNS servers distribute information—specifically, computer names and their IP addresses—one record at a time to a client upon request. Because a client needs to ask for the IP address by host name, that data is at little risk of interception. But attackers would love to get their hands on the complete contents of your DNS zones, and that information frequently travels between DNS servers, making it vulnerable to interception.

During DNS server synchronization, NT DNS servers send the complete zone file (in plaintext, as I mentioned earlier) even if just one record has changed. The only way to protect zone transfers between NT DNS servers is through a VPN tunnel or third-party encryption software. Upgrading your DNS servers to Win2K is usually simpler.

Because Win2K DNS supports incremental zone transfer (IXFR) for standard zones, Win2K DNS servers transfer only the records that have changed. This approach greatly reduces the opportunities to intercept an entire zone: Win2K DNS servers send the entire zone only when you add a new secondary DNS server. Zone transfer security is a key reason for implementing AD-integrated zones. These zones transfer DNS information as part of the AD replication process between DCs, so transfers are encrypted as well as incremental.

Another advantage of the AD-integrated zone transfer process is that DCs in only one domain can receive zone information. If you use standard zones and don't configure them properly, an attacker can prompt the zones to transfer complete zone information to any DNS server. Because anyone who has access to a client system can easily determine a DNS server's address, capturing zone information is even simpler than running a packet sniffer: Attackers can simply set up their own rogue DNS server, create a secondary zone, and in the process, request zone transfer from your DNS server.

You can protect standard zones from interception, but only by changing Microsoft's default configuration, which allows zone transfers to any server. On Win2K or NT, you should limit transfers to specific servers that are authorized DNS partners. To configure standard zones for limited zone transfer, complete the following steps:

Step 6: Secure DNS Updates
Although I strongly recommend Win2K DNS over NT DNS, Win2K DNS introduces some security concerns of its own. One concern is that a client computer can make changes to the DNS database. Win2K's dynamic DNS (DDNS) updates let clients and DHCP servers automatically—and remotely—perform the tedious task of maintaining a DNS database. (Under NT, changing the DNS database is a manual process that must be performed by administrators who are connected to the DNS server, making NT DNS more secure than Win2K DNS in this regard.) However, changing DNS records for even one system at a time offers an opportunity for an attacker to capture data, then use it to impersonate a crucial system.

For example, attackers have used spoofing on the public Internet to alter DNS servers and redirect users to false retail sites or pornographic sites. The far-reaching AlterNIC spoof of 1997 is one example of such an exploit. DNS, after all, controls the ultimate addressing of all traffic on a TCP/IP network. Malicious users can take advantage of the dynamic update feature to switch users from a legitimate system to an impersonator.

Security was clearly on the minds of Microsoft's Win2K DNS developers, and they addressed the possibility of attackers misusing dynamic updates. After a client registers with an AD-integrated zone that's configured to accept only secure updates, the client can change that DNS host record only if the client is authenticated by AD. Although Win2K DNS supports dynamic updates for standard zones, you can't secure those updates.

To configure an AD-integrated zone to require secure dynamic updates, follow these steps:

Worry-Free DNS
Because many administrators consider DNS a simple, low-risk or no-risk network function, they often overlook it when implementing security. Take these six steps to ensure that DNS doesn't become a security liability on your network.