Securing Your DNS Infrastructure | Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003

Because DNS was designed to be an open protocol, DNS data can be vulnerable to security attacks. Windows Server 2003 DNS provides improved security features to decrease this vulnerability. The DNS designer in your organization is responsible for creating a secure DNS infrastructure. The DNS administrators in your organization are responsible for maintaining network security by anticipating and mitigating new security threats.

Figure 3.10 shows the process for securing your DNS infrastructure.

click to expand
Figure 3.10: Securing Your DNS Infrastructure

Identifying DNS Security Threats

A DNS infrastructure is vulnerable to a number of types of security threats.

Footprinting The process of building a diagram, or footprint, of a DNS infrastructure by capturing DNS zone data such as domain names, computer names, and IP addresses for sensitive network resources. DNS domain and computer names often indicate the function or location of domains and computers.

Denial-of-service attack An attack in which the attacker attempts to deny the availability of network services by flooding one or more DNS servers in the network with recursive queries. When a DNS server is flooded with queries, its CPU usage eventually reaches its maximum and the DNS Server service becomes unavailable. Without a fully operating DNS server on the network, network services that use DNS are unavailable to network users.

Data modification The use of valid IP addresses in IP packets that an attacker has created to destroy data or conduct other attacks. Data modification is typically attempted on a DNS infrastructure that has already been foot printed. If the attack is successful, the packets appear to be coming from a valid IP address on the network. This is commonly called IP spoofing. With a valid IP address (an IP address within the IP address range of a subnet), an attacker can gain access to the network.

Redirection An attack in which an attacker is able to redirect queries for DNS names to servers that are under the control of the attacker. One method of redirection involves the attempt to pollute the DNS cache of a DNS server with erroneous DNS data that might direct future queries to servers that are under the control of an attacker. For example, if a query is made to example.contoso.com and a referral answer provides a record for a name that is outside of the contoso.com domain, the DNS server uses the cached data to resolve a query for the external name. Redirection can be accomplished when an attacker has writable access to DNS data, such as with non-secure dynamic updates.

For more information about common types of attacks, developing a security policy, and evaluating your level of risk, see "Designing an Authentication Strategy" and "Designing a Resource Authorization Strategy" in Designing and Deploying Directory and Security Services of this kit.

Developing a DNS Security Policy

If your DNS data is compromised, attackers can gain information about your network that can be used to compromise other services. For example, attackers can harm your organization in the following ways:

By using zone transfer, attackers can retrieve a list of all the hosts and their IP addresses in your network.
By using denial-of-service attacks, attackers can prevent e-mail from being delivered to and from your network, and they can prevent your Web server from being visible.
If attackers can change your zone data, they can set up fake Web servers, or cause e-mail to be redirected to their servers.

Your risk of attack varies depending on your exposure to the Internet. For a DNS server in a private network that uses a private namespace, a private addressing scheme, and an effective firewall, the risk of attack is lower and the possibility of discovering the intruder is greater. For a DNS server that is exposed to the Internet, the risk is higher.

Developing a DNS security policy involves:

Deciding what access your clients need, what tradeoffs you want to make between security and performance, and what data you most want to protect.
Familiarizing yourself with the security issues common to internal and external DNS servers.
Studying your name resolution traffic to see which clients can query which servers.

You can choose to adopt a low-level, mid-level, or high-level DNS security policy.

Low-Level DNS Security Policy

Low-level security does not require any additional configuration of your DNS deployment. Use this level of DNS security in a network environment in which you are not concerned about the integrity of your DNS data, or in a private network in which no external connectivity is possible. A low-level security policy includes the following characteristics:

All DNS servers in your network perform standard DNS resolution.
All DNS servers are configured with root hints that point to the root servers for the Internet.
All DNS servers permit zone transfers to any server.
All DNS servers are configured to listen on all of their IP addresses.
Secure cache against pollution is disabled on all DNS servers.
Dynamic update is allowed for all DNS zones.
User Datagram Protocol (UDP) and TCP/IP port 53 is open on the firewall for your network for both source and destination addresses.

Mid-Level DNS Security Policy

Mid-level DNS security consists of the DNS security features that are available without running DNS servers on domain controllers and storing DNS zones in Active Directory. A mid-level security policy includes the following characteristics:

The DNS infrastructure of your organization has limited exposure to the Internet.
All DNS servers are configured to use forwarders to point to a specific list of internal DNS servers when they cannot resolve names locally.
All DNS servers limit zone transfers to servers listed in the NS records in their zones.
DNS servers are configured to listen on specified IP addresses.
Secure cache against pollution is enabled on all DNS servers.
Secure dynamic update is allowed for all DNS zones.
Internal DNS servers communicate with external DNS servers through the firewall with a limited list of allowed source and destination addresses.
External DNS servers in front of your firewall are configured with root hints pointing to the root servers for the Internet.
All Internet name resolution is performed by using proxy servers and gateways.

High-Level DNS Security Policy

High-level DNS security uses the same configuration as mid-level security and also uses the security features available when the DNS Server service is running on a domain controller and DNS zones are stored in Active Directory. Also, high-level security completely eliminates DNS communication with the Internet. This is not a typical configuration, but it is recommended whenever Internet connectivity is not required. High-level security policy includes the following characteristics:

The DNS infrastructure of your organization has no Internet communication by means of internal DNS servers.
Your network uses an internal DNS root and namespace, where all authority for DNS zones is internal.
DNS servers that are configured with forwarders use internal DNS server IP addresses only.
All DNS servers limit zone transfers to specified IP addresses.
DNS servers are configured to listen on specified IP addresses.
Secure cache against pollution is enabled on all DNS servers.
Internal DNS servers are configured with root hints that point to the internal DNS servers hosting the root zone for your internal namespace.
Secure dynamic update is configured for all DNS zones except for the top-level and root zones, which do not allow dynamic updates at all.
All DNS servers are running on domain controllers. An access control list (ACL) is configured on the DNS Server service to allow only specific individuals to perform administrative tasks on DNS servers.
All DNS zones are stored in Active Directory. An ACL is configured to allow only specific individuals to create, delete, or modify DNS zones.
ACLs are configured on DNS resource records to allow only specific individuals to create, delete, or modify DNS data.

Note

Windows Server 2003 DNS does not support the use of DACLs on zones to control which clients or users can send queries to the DNS server.

Cache Pollution Protection

When cache pollution protection is enabled, the DNS server disregards DNS resource records that originate from DNS servers that are not authoritative for the resource records. Cache pollution protection is a significant security enhancement; however, when cache pollution protection is enabled, the number of DNS queries can increase.

In Windows Server 2003 DNS, cache pollution protection is enabled by default. You can disable cache pollution protection to reduce the number of DNS queries; however, to ensure the security of your system, it is strongly recommended that you leave cache pollution protection enabled on your DNS servers.

For information about cache pollution protection, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Securing DNS Servers That Are Exposed to the Internet

DNS servers that are exposed to the Internet are especially vulnerable to attack. You can secure your DNS servers that are exposed to the Internet by doing the following:

Place the DNS server on a perimeter network instead of your internal network.

For more information about perimeter networks, see "Deploying ISA Server" in this book.

Use one DNS server for publicly accessed services inside your perimeter network and a separate DNS server for your private internal network. This reduces the risk of exposing your private namespace, which can expose sensitive names and IP addresses to Internet-based users. It also increases performance because it decreases the number of resource records on the DNS server.
Add a secondary server on another subnet or network, or on an ISP. This protects you against denial-of-service attacks.
Eliminate single points of failure by securing your routers and DNS servers, and distributing your DNS servers geographically. Add secondary copies of your zones to at least one offsite DNS server.
Encrypt zone replication traffic by using Internet Protocol security (IPSec) or virtual private network (VPN) tunnels to hide the names and IP addresses from Internet-based users.
Configure firewalls to enforce packet filtering for UDP and TCP port 53.
Restrict the list of DNS servers that are allowed to initiate a zone transfer on the DNS server. Do this for each zone in your network.
Monitor the DNS logs and monitor your external DNS servers by using Event Viewer.

Securing Internal DNS Servers

Internal DNS servers are less vulnerable to attack than external DNS servers, but you still need to protect them. To secure your internal DNS servers:

Eliminate any single point of failure. Note, however, that DNS redundancy cannot help you if your clients cannot access any network services. Think about where the clients of each DNS zone are located, and how they resolve names if the DNS server is compromised and unable to answer queries.
Prevent unauthorized access to your servers. Allow only secure dynamic update for your zones and limit the list of DNS servers that are allowed to obtain a zone transfer.
Monitor the DNS logs and monitor your internal DNS servers by using Event Viewer. Monitoring your logs and your server can help you detect unauthorized modifications to your DNS server or zone files.
Implement Active Directory-integrated zones with secure dynamic update.

Securing Dynamically Updated DNS Zones

Use Active Directory-integrated zones and configure them for secure dynamic update. Secure dynamic update resolves the security risks associated with using dynamic update. Because dynamic update allows any computer to modify any record, an attacker can modify zone data, then impersonate existing servers.

For example, if you install the Web server, web.contoso.com, and it registers its IP address in DNS by using dynamic update, an attacker can install a second Web server, also name it web.contoso.com, and use dynamic update to modify the corresponding IP address in the DNS record. In this way, the attacker can impersonate the original Web server and capture secure information.

To prevent server impersonation, implement secure dynamic update. By using secure dynamic update, only the computers and users specified in an access control list (ACL) can modify objects within a zone.

If your security policy demands stricter security, modify these settings to further restrict access. Restrict access by computer, group, or user account, and assign permissions for the entire DNS zone and for the individual DNS names within the zone.

For more information about securing dynamically updated DNS zones, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

Securing DNS Zone Replication

Zone replication can occur either by means of zone transfer or as part of Active Directory replication. If you do not secure zone replication, you run the risk of exposing the names and IP addresses of your computers to attackers. You can secure DNS zone replication by doing the following:

Using Active Directory replication.
Encrypting zone replication sent over public networks such as the Internet.
Restricting zone transfer to authorized servers.

Using Active Directory Replication

Replicating zones as part of Active Directory replication provides the following security benefits:

Active Directory replication traffic is encrypted; therefore zone replication traffic is encrypted automatically.
The Active Directory domain controllers that perform replication are mutually authenticated, and impersonation is not possible.

Note

Use Active Directory-integrated zones whenever possible, because they are replicated as part of Active Directory replication, which is more secure than file-based zone transfer.

Encrypting Replication Traffic Sent Over Public Networks

Encrypt all replication traffic sent over public networks by using IPSec or VPN tunnels. When encrypting replication traffic sent over public networks:

Use the strongest level of encryption or VPN tunnel authentication that your servers can support.
Use the Windows Server 2003 Routing and Remote Access service to create the IPSec or VPN tunnel.

Restricting Zone Transfer to Authorized Servers

If you have secondary servers and you replicate your zone data by using zone transfer, configure your DNS servers to specify the secondary servers that are authorized to receive zone transfers. This prevents an attacker from using zone transfer to download zone data. If you are using Active Directory-integrated zones instead, configure your servers to disallow zone transfer.