Deploying Secure DNS

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

In a distributed environment, such as Active Directory, multiple servers work together to make the directory available to all users on the network. Advantages of the distributed model include elimination of single points of failure, shared resources for more efficient operation, and an administrative model that can be customized to match existing organizations.

Distributed environments require an infrastructure that allows the servers and clients to locate one another in the environment. In the case of Active Directory, this infrastructure is DNS.

Unauthorized users can attempt to use DNS to affect the directory environment in a variety of ways:

• They might corrupt or block the traffic between a computer that creates a DNS query and the computer that returns the response.

• They might corrupt the data on a DNS server or change it to invalid or incorrect information.

• They might shut down or disable the DNS server, making DNS information unavailable to clients and servers in the enterprise.

These types of attacks can have the results described in Table 43.

Table 43 Results of Attacks Made Through DNS

You can increase your protection of the DNS infrastructure at two levels:

• First, take steps to protect the integrity of a DNS server’s responses to client requests.

• Second, improve security for the DNS server — and therefore for the zone data that is stored on the server — so that unauthorized changes cannot be made to the zone data.

Protecting DNS Servers

When the integrity of the responses of a DNS server are compromised or corrupted, or when the DNS data is tampered with, clients can be misdirected to unauthorized locations without their knowledge. After the clients start communicating with these unauthorized locations, attempts can be made to gain access to information that is stored on the client computers. Spoofing and cache pollution are examples of this type of attack.

Another type of attack, the denial-of-service attack, attempts to incapacitate a DNS server to make DNS infrastructure unavailable in an enterprise. To protect your DNS servers from these types of attacks:

• Use IPsec between DNS clients and servers.

• Monitor network activity.

• Close all unused firewall ports.

Implementing IPsec Between DNS Clients and Servers

IPsec encrypts all traffic over a network connection. Encryption minimizes the risk that data that is sent between the DNS clients and the DNS servers can be scanned for sensitive information or tampered with by anyone attempting to collect information by monitoring traffic on the network. When IPsec is enabled, both ends of a connection are validated before communication begins. A client can be certain that the DNS server with which it is communicating is a valid server. Also, all communication over the connection is encrypted, thereby eliminating the possibility of tampering with client communication. Encryption prevents spoofing attacks, which are false responses to DNS client queries by unauthorized sources that act like a DNS server.

IPsec is not enabled by default. Many organizations choose not to enable IPsec across their entire network because it might have an impact on the performance of the network.

For more information about IPsec, see IPsec (https://go.microsoft.com/fwlink/?LinkID=93520).

Monitoring Network Activity

Denial-of-service attacks result in the flooding of a DNS server with so many client requests that the DNS server cannot keep up with the legitimate requests, and it stops responding to DNS queries. To help guard against denial-of-service attacks, watch for unusually high amounts of traffic, and look for anomalies such as a high volume from a single location or high volume for a single type of traffic.

Closing All Unused Firewall Ports

Firewalls are a common way to protect servers from outside attack. Firewalls limit the available ports that can be used to communicate between points on your network. DNS servers use User Datagram Protocol (UDP) port 53 to communicate with one another. Open port 53 on firewalls when a firewall is located between:

• DNS servers that perform zone transfers

• DNS servers that delegate zones and the server that is authoritative for the zone

• DNS clients and their DNS servers

• DNS forwarders and servers that are higher in the DNS namespace hierarchy

For more information about managing Active Directory across firewalls, see Active Directory in Networks Segmented by Firewalls (https://go.microsoft.com/fwlink/?LinkId=140089).

Protecting DNS Data

If an attacker can gain access to the server itself, the attacker might attempt to alter data that is stored in the DNS zone files. To help keep your zone data secure from a direct attack:

• Use secure dynamic update.

• Set quotas to limit registration of DNS resource records.

• Ensure that DNS administrators are trusted.

• Delegate administration of DNS data.

• Use the appropriate routing mechanism for your environment:

  • Conditional forwarders

  • Secondary zones

  • Root hints

• Use separate internal and external DNS namespaces.

• Disable recursion on DNS servers that do not respond to DNS clients directly and that are not configured with forwarders.

Using Secure Dynamic Update

Secure dynamic update is the default method of DNS update in both Windows 2000 and Windows Server 2003. Secure dynamic update prevents the type of DNS attack that involves entering invalid data into the zone files. If an attacker enters invalid data into the zone files, the attacker can:

• Add records that contain invalid IP addresses, causing misdirection of clients for denial of service or misdirection to unauthorized servers.

• Register dummy records for a denial-of-service attack. Possible goals of this type of attack are to:

  • Exhaust the server’s disk space by generating a huge zone file filled with dummy records.

  • Slow zone replication by creating a huge number of entries (more than 50,000) in the zone container.

To allow only trusted, authenticated users to register records, use secure dynamic update. Using secure dynamic update guarantees that registration requests are processed only if they are sent from authenticated clients in the forest. This requirement makes it more difficult for a rogue user to launch these types of attacks because the rogue user must be a member of the Authenticated Users group or have more powerful credentials to gain access. To prevent a rogue user from registering bad records, secure dynamic update is used by default in Windows 2000 and Windows Server 2003.

Using Quotas to Limit the Number of DNS Resource Records That Can Be Registered

As described in "Setting Object Ownership Quotas" in the Establishing Secure Data Administration Practices section, you can use quotas in combination with security groups to manage the objects that are created in Active Directory. When you use Active Directory–integrated DNS, zone data can be stored in the domain directory partition (if you want DNS data to replicate to all domain controllers) or in application directory partitions (if you want DNS data to replicate only to domain controllers that are DNS servers).

By default, members of the Authenticated Users group have the ability to create resource records on DNS servers that are in the domain of the client computer. This ability enables all computers to dynamically update DNS zone data. A typical authenticated user registers a maximum of 10 records in DNS. To ensure that malicious users or applications do not create inappropriate resource records, you can set a default quota on the application directory partitions ForestDnsZones and DomainDnsZones (if DNS data is replicated to all domain controllers that are DNS servers for the forest or domain — available in Windows Server 2003) or on the domain directory partitions (if DNS data is replicated to all domain controllers for the domain — required in Windows 2000 Server). A default limit of 10 objects ensures that all computers can update DNS appropriately but cannot start denial-of-service attacks.

Explicit Quotas for Domain Controllers and Other Servers

The number of resource records that must be registered in DNS is significantly greater for domain controllers and for multihomed computers that register adapter-specific records for all of their connections. To accommodate the resource record requirements of atypical authenticated users such as domain controllers, multihomed computers, and multi-adapter servers, create special groups for these specific types of computers. For example, you might create an Enterprise Domain Controllers group that has all domain controllers as members. To ensure that this group can create the maximum DNS resource records that might be required, set a quota of 300 to 400 objects for this group on the DomainDnsZones and ForestDnsZones application directory partitions or on the domain directory partitions, depending on the replication scope.

The same rule applies to certain servers, such as VPN or Web servers, that are required to register a large number of resource records in DNS. Depending on how many adapter-specific resource records your VPN or Web server must register, you can create a group for those servers and assign the appropriate quota to ensure that the Authenticated Users default quota does not apply.

Explicit Quotas for DHCP Servers

To allow DHCP servers to have an essentially unlimited ability to create resource records, when clients depend on DHCP-assigned IP addresses, you can create a group that contains all DHCP servers in the domain or forest and then set an explicit quota assignment for that group on the DomainDnsZones and ForestDnsZones application directory partitions, respectively, or on the domain directory partitions (if DNS data is replicated to all domain controllers). Set a quota that is appropriate to the number of clients for which your DHCP server registers records, multiplied by the upper limit of the number of records that are registered per computer. This way, DHCP servers can update DNS with client resource records as needed.

For more information about directory quotas and how to use the dsadd, dsmod, and dsquery commands to manage them, see "Directory data store" and the respective topics for each command in Help and Support Center for Windows Server 2003.

Ensuring That Only Trusted Individuals Are Granted DNS Administrator Privileges

Members of the DNS Admins group have control over the configuration of the DNS environment. This control means that they can disrupt the functionality of the directory service by using denial-of-service attacks or by misdirecting clients to rogue servers, which puts them in the same category as the service administrator accounts that are mentioned in "Chapter 5: Establishing Secure Administrative Practices" earlier in this guide. Use the same care in determining who is granted membership in the DNS Admins group. Choose only individuals who are aware of your operational policies and who have demonstrated their willingness to enforce those policies. Also, grant access only to the portion of the DNS infrastructure for which each individual is responsible.

Delegating Administration of DNS Data

Permissions can be set on the zone containers to limit access by users who attempt to modify them with management tools, such as the DNS snap-in or ADSI Edit. By default, Administrators, Domain Admins, Enterprise Admins, and DNS Admins have Full Control access to all components of DNS. Everyone else has Read access.

Using Appropriate Routing Mechanisms

DNS queries can be routed to the appropriate DNS server through the following mechanisms:

• Conditional forwarding, to specify the server to query for a given suffix

• Secondary zones, to provide DNS zone data redundancy

• Root hints, to enable any DNS client to find the DNS server for any name in the namespace by using the delegations that start at the zone for the root domain

If a firewall is deployed between two Active Directory namespaces that are serviced by different DNS servers, conditional forwarding requires that only the forwarder (the server to which queries are being forwarded) be accessible. In the case of secondary zones or delegations that might be used for the same purpose, all ports need to be accessible. In this case, queries are not recursively resolved by the server. Instead, a referral to another DNS server is returned.

If you plan to deploy secondary zones in your DNS infrastructure, consider using forwarders instead. Secondary zone data is not stored in Active Directory; it is stored in a text-based zone file, which makes the data more vulnerable to attack. It is possible to use NTFS permissions to protect the data; however, eliminating the existence of the zone file altogether removes the need to protect such data. Using forwarders accomplishes distribution of the load on the DNS servers; however, forwarders do not require zone files to be stored on every server. They simply forward DNS requests to servers that have the zone data. Using forwarders reduces the potential surface area for attacks on your DNS deployment.

The downside of using forwarders is an increase in traffic on your network and a reduction in the fault tolerance of your DNS infrastructure. Forwarders do not maintain their own copy of the database. When they receive a client query, forwarders first check their own DNS cache to see if the query has been processed before and if the result is in memory. If the result is not in memory, a query is sent to the forwarders’ primary DNS server to be processed. Because forwarders must always forward new queries, rather than processing them in a local database, forwarders end up generating more traffic on the network. The reduction in fault tolerance occurs because the use of forwarders means that there are fewer copies of the database available in case a DNS server fails. When a primary or secondary DNS server fails, it means that there is one less DNS server available to process client requests. If you are using forwarders, and the primary DNS server that is used by the forwarders fails, the primary DNS server and all the forwarders become unavailable.

Root hints enable any DNS server to query the DNS servers that host the zone for the root domain. If you have an internal DNS root in your DNS infrastructure, configure the root hints of internal DNS servers to point only to the DNS servers hosting your root domain, not to the DNS servers hosting the Internet root domain. This configuration prevents your internal DNS servers from sending private information over the Internet when they resolve names.

Using Separate Internal and External DNS Namespaces

If your organization requires an Internet presence, create separate namespaces for use on the Internet and on your intranet. DNS was designed to distribute information in response to queries from clients. It was not designed to provide secure access to the information it distributes. For this reason, DNS environments are vulnerable to attacks that cause information disclosure.

As security becomes a higher and higher priority for network operations, features have been added to DNS to make it a more secure environment. However, these features are geared more toward preventing the registration of invalid information than preventing information disclosure. A DNS server responds to any DNS client queries that are applicable to the zone for which the DNS server is authoritative. It does not perform any kind of security check to make sure that a valid user or client is making the query. If you use the same namespace for your Internet presence and your intranet, clients on the Internet can send queries to your DNS servers in an attempt to learn the names of resources on your intranet.

Most organizations have an internal DNS infrastructure — for name resolution of internal resources — and a separate external DNS infrastructure that gives them a presence on the public Internet. This type of DNS infrastructure, called a split namespace, consists of a set of DNS servers for the internal namespace and a separate set of DNS servers for the external namespace. A split namespace ensures that users who query for an external name cannot access or get information about an internal resource.

Disabling Recursion

By default, recursion is enabled for the DNS Server service, and clients typically request that the server use recursion to resolve a name when they send a query. A DNS server requires recursion only if it responds to recursive queries from DNS clients or if it is configured with a forwarder. If recursion is disabled, the DNS Server service always uses referral, regardless of the client request.

In general, DNS servers can answer queries for names outside their authoritative zones in two ways:

• Referrals: Servers can send referral answers, which are an immediate response to the requesting client of a list of resource records for other DNS servers that can help in resolving the queried name.

• Recursion: Servers can use recursion to query other servers on behalf of the requesting client, attempting to fully resolve the name. Recursive lookups continue until the server receives an authoritative answer for the queried name. The server then forwards this answer in response to the original query from the requesting client.

In most cases, disabling recursion on a DNS server is recommended when DNS clients are limited to resolving names that are managed authoritatively on a specific server. This limitation occurs when a DNS server has DNS names data only for an internal network. It also occurs when the DNS server is incapable of resolving external DNS names (such as Internet DNS names) and clients are expected to try another DNS server to resolve these names. When there is no need for a server to answer queries for data that it does not host, ensuring that a DNS server does not query other servers helps prevent attacks in cases where repeated client queries might cause a DNS server to query servers that are located outside an internal, protected network. Disabling recursion minimizes unnecessary load on the server and ensures that extraneous data from external DNS servers is not cached by the server that is providing recursion.

For more information about securing DNS, see "Checklist: Securing your DNS infrastructure" in Help and Support Center for Windows Server 2003. For more information about configuring DNS, see "Designing the Active Directory Logical Structure" in Designing and Deploying Directory and Security Services and "Deploying DNS" in Deploying Network Services of the Windows Server 2003 Deployment Kit (or see "Designing the Active Directory Logical Structure" on the Web at https://go.microsoft.com/fwlink/?LinkId=4723 and "Deploying DNS" on the Web at https://go.microsoft.com/fwlink/?LinkId=4709).