SolutionBase: Countering DNS security threats

DNS helps workstations access network and Internet resources, but it can also be a vulnerable point of attack. Brien Posey discusses some of the common DNS attack points and how to counter them.

This article is also available as a TechRepublic download.

As I'm sure you know, your DNS server is one of the most critical components in your network infrastructure. Your DNS server is not only necessary for resolving Internet domain names, but Active Directory absolutely cannot function without it. That being the case, it is in your best interest to protect your DNS server from various security threats.

The types of threats that exist against your DNS server vary depending on your network architecture. For example, a company whose DNS server is exposed to the outside world would likely face an entirely different set of threats than a company who used a DNS server solely for internal purposes. In this article, I will discuss a variety of threats to your company's DNS server. As I do, I will also describe various countermeasures to those threats.

Denial of Service Attacks

A denial of service attack is probably the least sophisticated form of attack against your DNS server. Even so, it is a threat that you must take seriously, because a denial of service attack can cripple your network.

The basic idea behind a DNS related denial of service attack is that the attacker floods your DNS server with so many recursive queries that the DNS server becomes bogged down by these queries and is unable to service legitimate requests as a result. One thing to keep in mind as I discuss denial of service attacks is that while the attack method is generally performed the same way in each situation, the reason why the attack works varies from network to network. On some networks, a denial of service attack might work because it pushes the server's CPU to 100% utilization, and the server has no processing power left to deal with other inbound requests. In other situations, a denial of service attack might consume all of a company's Internet bandwidth, making the DNS server inaccessible to external users while it remains internally accessible.

In either case, there are some things that you can do to mitigate the effects of a denial of service attack. A denial of service attack against your DNS server is the most likely to occur if you have a publically accessible DNS server that is authoritative for your company's Internet domain name.

In situations like this, redundancy is the key to not falling victim to a denial of service attack. If your DNS server also handles name resolutions for your internal network, then you should consider investing in additional DNS servers.

There are a couple of different ways that you could use these additional DNS servers. One option is to implement a load balancing type solution so that multiple DNS servers are available to service name resolution queries. This technique allows your DNS servers to handle a much greater workload than a single DNS server could handle by itself. Keep in mind though that a determined attacker will still be able to find a way to overwhelm the DNS servers and accomplish a successful denial of service attack.

While load balancing is a good idea if you are concerned about denial of service attacks, another good idea is to isolate your internal DNS server from your external DNS server. I have seen at least a couple of real world situations in which companies have tried to save a few bucks by using a single DNS server to handle both internal and external name resolution requests.

While this type of arrangement can be made functional, it is a really bad idea from a security standpoint. Remember that Active Directory is completely dependent on DNS services. If a single DNS server is carrying the entire name resolution burden for your organization, and someone launches a denial of service attack against that server, then your Active Directory will come to a grinding halt. Computers on your internal network will be unable to resolve the IP addresses of other computers on your network.

As you can see, a denial of service attack against your DNS server is bad, but it is a lot worse if that DNS server also handles the name resolutions for your internal network. Therefore, I strongly recommend dedicating a server on your private network to the task of performing internal name resolutions (actually, you should have at least two dedicated DNS servers in case the primary DNS server fails). If you need to host your own external DNS server, then use a dedicated server that will only resolve resources that are accessible over the Internet.


Another reason why it is important to keep your internal name resolution functions isolated from the outside world is to combat a technique called footprinting. Footprinting isn't actually an attack method itself, but rather a technique used for gathering information in preparation for an attack. The idea is that the would-be attacker can use a network sniffer to analyze all of the DNS related traffic flowing across your network. By doing so, the attacker can not only learn the names and IP addresses of the servers on your network, but also the functions of some servers.

If this statement seems a little far-fetched, then there are two things to consider. First, name resolution requests are rarely encrypted, which means that anyone with access to the network segment that the requests are flowing over can view the requests and responses. Second, host records are only one of several types of records stored on a DNS server. An attacker can use other types of records to identify a server's function. For example, if an attacker wanted to know which server was your mail server, they could watch for requests involving an MX records.

The problem with using this technique for footprinting and is that an attacker has to use a packet sniffer and capture a lot of data. Because there are methods for detecting packet sniffing, the attacker risks detection. Even if the attacker is not caught, they still have the tedious task of analyzing all of the data once the packet capture is complete.

A much more efficient footprinting technique involves capturing zone transfer data. This technique involves the attacker setting up their own DNS server as a secondary zone server, and then requesting a zone data transfer from the primary DNS server. The technique is quick, clean, and it gives the attacker a complete copy of the DNS records for the entire zone.

By far the best way to prevent this type of footprinting is to run the DNS services on domain controllers, and use Active Directory integrated zones. The reason for doing so is that Active Directory becomes responsible for performing zone replication. At first, this might not seem like a big deal but remember that domain controllers authenticate each other prior to exchanging data. This means that an attacker can not use a simple technique such as IP spoofing to impersonate a domain controller and receive the zone transfer information.

Another reason why it is advisable to use Active Directory integrated zones and hosts the DNS services on domain controllers is because Active Directory related traffic between domain controllers is encrypted. This prevents a would-be attacker from using a packet sniffer to intercept a zone transfer, although the attacker can still snoop on name resolution requests if they have access to the segment that the requests are flowing over.

I have shown you how an attacker can use a rogue DNS server to create a secondary zone, and issue a zone transfer request. One of the most important techniques in preventing this type of attack is to specify the IP addresses of the DNS servers that you will allow to take part in zone transfers.

Windows Server 2003 is configured by default to allow zone transfers with any DNS server. You can change this by opening the DNS management console, right-clicking on the zone that you want to protect, and selecting the Properties command from the resulting shortcut menu. When you do, you'll see the zone's properties sheet. The properties sheet's Zone Transfer tab allows you to specify the IP addresses of DNS servers to which zone transfers are allowed.

Cache Pollution

Another type of DNS related exploit that I want to talk about is cache pollution. The best way that I can think of to describe cache pollution is to compare it to browser hijacking. I'm sure that at one point or another you have probably seen a machine that is badly infected with spyware. Some types of spyware are designed to hijack the browser so that when common URLs are entered, the browser is actually directed to a malicious Website rather than to the requested Website. Cache pollution accomplishes something similar, but does so at the DFS level.

Cache pollution is possible because DNS servers allow query responses to contain various resource records. For example, suppose that I wanted to hijack requests that were destined for a popular Websites such as I could accomplish this by setting up a malicious Website and a DNS server that is authoritative for that site. I could then set the DNS server up so that when someone performed a name resolution query on the domain name associated with the Website that I had created, the DNS server would return the Web servers IP address, but would also return some other resource records that were completely unrelated to the requested Website. Among these resource records would be a record that specifies an incorrect IP address for the Google Website. This incorrect IP address would of course point to a malicious Website.

As you can see, this resource record would essentially poison the cache of the DNS server that issued the name resolution request. This means that when users attempt to perform a name resolution query on the Website, the DNS servers cache will already contain a record for the Website, but the record will contain the IP address of a malicious Website.

Fortunately, Windows Server 2003 contains a built-in defense mechanism against cache pollution. This mechanism is not enabled by default though, so you will have to enable it if you want to be protected against cache pollution.

To protect your server against cache pollution, open the DNS management console, right-click on the listing for your DNS server, and select the Properties command from the resulting shortcut menu. This will cause the console to display the server's properties sheet. At this point, you should select the properties sheet's Advanced tab. Now, select the Secure Cache Against Pollution check box and click OK.

In case you're wondering, cache pollution protection works by preventing the server from caching unrelated resource records that might be included in the response to a name resolution query.

Securing Dynamic Updates

One last security issue that I want to talk about is that of securing dynamic DNS updates. Once upon a time, network administrators created all DNS records by hand. Eventually though, manually creating host records became impractical as DHCP servers became more prevalent. As I'm sure you know, DHCP servers dynamically assign IP addresses to network hosts. The problem with this is that a host's IP address can change frequently. As such, it is impractical for an administrator to try to update host records every time that the DHCP server decides to assign a host a different IP address.

Dynamic updates were created as a solution to this problem. The idea is that any time the DHCP server assigns an IP address to a network host, a DNS host record can be dynamically created or updated. Of course this opens the door to security problems. An attacker could easily spoof a dynamic update message and trick the DNS server into thinking that the IP address for one of your network hosts has changed. For example, an attacker might update a DNS host record so that requests for your company's Website are directed to a malicious Website under the attacker's control.

The best defense against dynamic update attacks is to use only Active Directory integrated zones, and to require secure dynamic updates. You can enable secure dynamic updates by opening the DNS management console, right-clicking on a zone that you want to protect, and selecting the Properties command from the resulting shortcut menu. When the zone's properties sheet opens, go to the General tab and select the Secure Only option from the Dynamic Updates drop down list.

Know thy enemy

As you can see, there are a number of different attacks that can be used against a DNS server. Being that your DNS server is one of the most critical pieces of your network infrastructure, it is important to protect it against these exploits.

Editor's Picks

Free Newsletters, In your Inbox