Windows Sever 2003 : Planning DNS Security

11/6/2012 1:05:20 AM
Although DNS servers perform functions that are intrinsically benign, the possibility of their compromise does pose a significant threat to your network security. Part of the design process for your name resolution strategy is keeping your DNS servers, and the information they contain, safe from intrusion by potential predators.

Determining DNS Security Threats

DNS name resolution is an essential part of TCP/IP networking. Both Internet and Active Directory communications rely on the ability of DNS servers to supply clients with the IP addresses they need. There are two primary security threats associated with DNS: interruption of service and compromise of DNS data. As part of your name resolution strategy, you must evaluate the threats to your DNS servers and the possible consequences, and then take steps to protect the servers without compromising their functionality.

Some potential threats to your DNS servers are as follows:

  • Denial-of-service (DoS) attacks Flooding a DNS server with huge numbers of recursive queries can eventually force the processor to 100 percent usage, preventing the server from processing name resolution requests from actual clients. This type of attack does not require a great deal of skill from the attacker and can be extremely effective in shutting down a network. The inability to resolve DNS names can prevent users from accessing Internet resources and even from logging on to Active Directory servers.

  • Footprinting Intruders gather information about a network’s infrastructure by intercepting DNS data, usually to identify targets. By capturing DNS traffic, intruders can learn the domain names, host names, and IP addresses you are using on your network. This information frequently discloses the functions of specific computers on the network, enabling the intruder to decide which ones are worth attacking in other ways.

  • IP spoofing Intruders can use a legitimate IP address (often obtained through footprinting) to gain access to network services or to send damaging packets to network computers. Spoofing can enable packets to get through filters that are designed to block traffic from unauthorized IP addresses. Once granted access to computers and services by using this technique, the attacker can cause a great deal of damage.

  • Redirection In this type of attack, an intruder causes a DNS server to forward name resolution request messages to an incorrect server that is under the attacker’s control. The attacker usually accomplishes this by corrupting the DNS cache in a server that is using unsecured dynamic updates.

Securing DNS

A number of techniques can protect your DNS servers and your namespace data from attack, and it is up to you to locate the threats to your servers and to determine what steps to take to protect against them. As with most security problems, it is just as possible to err on the side of caution as it is to be negligent. As an example of negligence, not implementing security measures can leave your DNS servers open to access from the Internet and can allow them to exchange zone data and dynamic updates with any other computer. This leaves the servers vulnerable to any of the attacks described in the previous section.

At the opposite extreme, you can close off your network from the outside world by denying all Internet access, creating an internal root, using Active Directory domain controllers for your DNS servers, limiting administrative access to the DNS servers, and encrypting all DNS communications. These measures secure the DNS servers from most forms of attack, but they also compromise the functionality of the network by preventing users from accessing the Internet. There certainly are times when extreme measures like these are warranted, but it is up to you to decide what level of security your network requires.

Some of the security measures you can use to protect your DNS servers from external (and even internal) intrusion are described in the following sections.

Providing Redundant DNS Services

When you use registered domain names on your network, your DNS servers must be accessible from the Internet, and they are therefore vulnerable to DoS attacks and other forms of intrusion. To prevent intruders from crippling your network by these attacks, it is a good idea to use multiple DNS servers to provide redundant services to your users. This type of protection can be as simple as configuring your DNS clients to use your ISP’s DNS server when yours is unavailable or unresponsive. This way, your users can continue to access Internet services even when someone disables your own DNS server by a DoS attack. Unless the intruder attacks both your DNS server and the ISP’s DNS server, name resolution services continue to function properly.


You can also deploy your own redundant DNS servers to provide even more protection. Placing a second server on another subnet, or at another site, can give your users a fallback in case an attack takes place on one of the servers. In addition, running your own servers enables you to provide redundant name resolution services for Active Directory, which your ISP’s DNS servers probably cannot do.

Deploying multiple DNS servers is also a way to protect your namespace from footprinting. Install one server on your perimeter network, for Internet name resolution, and another on your internal network, to host your private namespace and provide internal name resolution services. Then configure the internal DNS server to forward all Internet name resolution requests to the external DNS server. This way, no computers on the Internet communicate directly with your internal DNS server, making it less vulnerable to all kinds of attacks.

Limiting DNS Interface Access

Another way of securing DNS servers against unauthorized access from the Internet is to limit the network interfaces over which the server can receive name resolution requests. If you have configured your DNS server computer with multiple IP addresses, you can click the Interfaces tab in the server’s Properties dialog box in the DNS console and specify the IP addresses that DNS clients can use to contact the server. (See Figure 1.) For example, if a server is connected to both an internal network and to the Internet, you can prevent the server from receiving name resolution requests that originate on the Internet.

Figure 1. The Interfaces tab in a DNS server’s Properties dialog box

Securing Zone Replication

Although it is possible to footprint a namespace by capturing name resolution traffic, a more efficient method (for the attacker) is to intercept zone replication traffic. By capturing zone transfer packets, for example, an intruder can get a complete picture of a zone and all its domains and hosts at once.

The best and simplest way to secure zone replication traffic is to deploy all your DNS servers on your domain controllers and store all your zones in Active Directory. Active Directory is then responsible for performing all zone replication. All Active Directory domain controllers perform a mutual authentication procedure before they exchange data, so a potential intruder cannot use IP spoofing to impersonate a domain controller. In addition, Active Directory encrypts all traffic, which prevents anyone capturing the packets from reading the data they contain. Finally, access to the domain controllers themselves is restricted by the policies you already have in place to protect your other Active Directory data.


If you cannot use Active Directory–integrated zones on your network, you must create standard file-based zones and use zone transfers to replicate the DNS namespace data. Although zone transfers are inherently less secure than Active Directory replication, there are still techniques you can use to prevent intruders from intercepting your DNS data.

One way to protect zone transfer data is to specify the IP addresses of the DNS servers that you allow to participate in zone transfers. If you do not do this, a potential intruder can simply install a DNS server, create a secondary zone, and request a zone transfer from your primary zone. The intruder then has a complete copy of your zone and all the information in it.

To limit zone transfers on a Windows Server 2003 DNS server, open the DNS console, display the Properties dialog box for a primary zone, and then click the Zone Transfers tab to display the dialog box shown in Figure 2. Select the Allow Zone Transfers check box, and then choose either the Only To Servers Listed On The Name Servers Tab or Only To The Following Servers option. You can then specify, in either the IP Address text box or the Name Servers tab, the IP addresses of the DNS servers that contain your secondary zones.

Figure 2. The Zone Transfers tab in a DNS zone’s Properties dialog box

Although the preceding technique can prevent unauthorized DNS servers from receiving zone transfers, it does not protect the packets containing the zone transfer data themselves. An intruder with a protocol analyzer, such as the Microsoft Network Monitor application, can capture the zone transfer traffic and read the data inside the packets. To prevent this, you can configure your DNS servers to encrypt their traffic using the Internet Protocol Security extensions (IPSec) or virtual private networking.

Preventing Cache Corruption

Potential attackers might try to load a DNS server’s name cache with incorrect information in an effort to redirect client connections to other servers and gather information from the clients. The Windows Server 2003 DNS server includes a feature that helps to prevent corruption of the cache. In a DNS server’s Properties dialog box, click the Advanced tab (shown in Figure 3) and then select the Secure Cache Against Pollution check box under Server Options.

Figure 3. The Advanced tab in a DNS server’s Properties dialog box

Activating this feature prevents the server from caching unrelated resource records included in reply messages. For example, if a DNS server sends a query to an Internet server requesting the resolution of a name in the domain, it would normally cache all the resource records supplied by the Internet server, no matter what information they contained. If you activate the Secure Cache Against Pollution option, however, the DNS server caches only resource records for names in the domain. The server ignores all records for names in other domains.

Using Secure Dynamic Update

As DNS was originally designed, administrators had to create all resource records by hand, typing the host name of each computer and its IP address or other information. This eventually became a problem as the use of automatic IP addressing solutions such as the Dynamic Host Configuration Protocol (DHCP) became more prevalent. DHCP is designed to automatically supply IP addresses and other TCP/IP configuration parameters to computers, which means that it is possible for a computer’s IP address to change periodically. Because it would be impractical for network administrators to keep track of these changes and modify the appropriate resource records manually, the developers of DNS created a new standard, referred to as dynamic update.

Dynamic update enables DNS clients on the network to send messages to their DNS servers during system startup. These messages contain the IP addresses the DHCP server has assigned to the clients, and this information is used by the DNS server to update its resource records with the new information.

Although dynamic update saves DNS administrators a lot of work, it also leaves the DNS servers vulnerable to serious forms of attack. An intruder could create a false dynamic update message and send it to your network’s DNS server. The message could state that your company’s Internet Web server has changed its IP address, forcing your DNS server to add a counterfeit address to the resource record for the Web server’s host name. From then on, Internet traffic intended for your company Web server would be redirected to a server under the attacker’s control.

To prevent this from occurring, you should create Active Directory–integrated zones whenever possible and configure them to accept only secure dynamic updates. The procedure is to display the zone’s Properties dialog box, click the General tab, and from the Dynamic Updates drop-down list, select Secure Only. (See Figure 4.)

Figure 4. The General tab in a DNS zone’s Properties dialog box

Using Standard Security Measures

In addition to these specialized DNS security measures, you can also protect your Windows Server 2003 DNS servers from attack using the same techniques you use for any computer on your network. Limiting physical access to the server and using permissions to control administrative access are basics that you should include in the case of a DNS server, because intruders can come from inside the organization as well as from outside. You can also use the packet filtering capabilities of your firewall to control access to the computer itself and to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port number 53, which is the well-known port number for DNS.

Most View
Looking Good, Sounding Great (Part 1) : Q Acoustics Q7000i 5.1, Bowers & Wilkins MT-50, Canton Movie 1050
Booting on HP 9000 Servers (part 2) - The setboot Command, Boot Console Handler (BCH) and Processor Dependent Code (PDC)
Sony Xperia ZL Review - A Powerhouse Phone In An Amazingly Compact Chassis (Part 3)
Long Awaited Canon Super Telephoto Emerges From The Wild
Sling Media Slingbox Pro-HD
Ouya Gaming Machine Review - Founding Backer Version (Part 1)
Seasonic And Enhance Junior PSUs - Compact Power Supply (Part 5) : Enhance ENP-7025E
SQL Server 2008 : Common performance problems (part 1) - Procedure cache bloating
ECS Z77H2-A2X v1.0 - Golden LGA 1155 Mainboard From The Black Series (Part 6)
Booting on HP 9000 Servers (part 4) - HPUX Secondary System Loader (hpux)
Top 10
SQL Server 2012 : Consolidating Data Capture with SQLdiag - Getting Friendly with SQLdiag (part 2) - Using SQLdiag as a Service
SQL Server 2012 : Consolidating Data Capture with SQLdiag - Getting Friendly with SQLdiag (part 1) - Using SQLdiag as a Command-line Application
SQL Server 2012 : Consolidating Data Capture with SQLdiag - The Data Collection Dilemma, An Approach to Data Collection
SQL Server 2012 : Troubleshooting Methodology and Practices - Data Analysis, Validating and Implementing Resolution
SQL Server 2012 : Troubleshooting Methodology and Practices - Data Collection
SQL Server 2012 : Troubleshooting Methodology and Practices - Defining the Problem
SQL Server 2012 : Troubleshooting Methodology and Practices - Approaching Problems
Windows 8 : Accessing System Image Backup and Recovery Functionality with Windows Backup, Cloud Backup
Windows 8 : Using the Windows 8 Recovery Tools (part 2) - Push Button Reset
Windows 8 : Using the Windows 8 Recovery Tools (part 1) - Creating a System Recovery Disc, Booting to the Windows Recovery Environment