Securing DNS Servers

Securing DNS Servers

When planning the security of DNS servers, you should prepare for attacks against both DNS clients and DNS servers. Both can lead to clients being directed to unauthorized DNS servers or referenced to incorrect servers via fraudulent DNS resource records. By implementing the following security measures, you can reduce the probability of a successful attack against your DNS server. These measures increase the security of your DNS servers and lessen the chances of a successful attack:

• Implementing Active Directory integrated zones

• Implementing separate internal and external DNS name servers

• Restricting zone transfers

• Implementing IP Security (IPSec) between DNS clients and servers

• Restricting DNS traffic at the firewall

• Limiting management of DNS

• Protecting the DNS cache

Implementing Active Directory Integrated Zones

Active Directory integrated zones store zone information in the domain naming context, rather than in plaintext files on the local file system. An Active Directory integrated zone implements each resource record as a separate dnsNode object in the following Active Directory location:

DC=DNSZoneName, CN=MicrosoftDNS, CN=System, DC=DomainDN

DNSZoneName is the DNS fully qualified domain name (FQDN) of the DNS zone, and DomainDN is the LDAP distinguished name of the Active Directory domain where the DNS zone is stored. For example, the zone named example.com stored in an Active Directory domain named south.example.com would be stored in the following location:

DC=example.com, CN=MicrosoftDNS, CN=System, DC=south,DC=example,DC=com

The zone information is replicated to all other domain controllers in the domain. This information is accessible to DNS clients if the DNS service is installed at a specific domain controller and if the DNS clients are configured to use that domain controller as a DNS server.

If the zone must be hosted on DNS servers in other domains, the DNS servers in those domains must be configured with secondary zones, with the domain controllers in the initial domain acting as master DNS servers for the zone. Active Directory replication does not provide replication of Active Directory integrated zones to other domains in the forest.

Because each DNS resource record is stored as a separate dnsNode object, each resource record has its own individual DACL. By default, the only security principals with the permission to modify a DNS resource record are members of the local Administrators group, the Domain Admins group, the Enterprise Admins group, the DNSAdmins group, and the Enterprise Domain Controllers group, as well as the computer account that registered the DNS resource record with the DNS zone if you have enabled Secure Dynamic Updates for the zone.

Implementing Separate Internal and External DNS Name Servers

Even if you implement the same DNS namespace on both the private and public networks, you should create separate zones for the internal and external DNS servers. The external DNS servers must contain only externally accessible DNS resource records. The internal DNS servers must contain internally accessible DNS resource records and can contain externally accessible DNS resource records, depending on the namespace implemented for Active Directory and the addressing scheme implemented in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet) of the network. See Figure 15-1 for an example of this DNS configuration.

Figure 15-1. A namespace protected by implementing separate external and internal DNS servers

Implementing separate internal and external DNS servers might require you to include external resource records in the internal DNS zone. You need to do this when the Active Directory forest root uses the same DNS domain name as the external network or when you want to reference the externally accessible resources by their true IP addresses in the perimeter network, rather than using the addresses published to the Internet by the firewall protecting the perimeter network.

If the same namespace is used both internally and externally, you cannot use forwarders to resolve the DNS resource records hosted at the external DNS server because the internal DNS server is authoritative for the DNS zone. If the resource record is not found in an authoritative zone, DNS reports that the resource record does not exist and the DNS request will not be forwarded to the configured forwarder.

Restricting Zone Transfers

Another method that attackers can use to obtain DNS zone data is to perform a zone transfer, transferring all DNS resource records from the target DNS zone. Attackers can accomplish this by typing the following command within the Nslookup console:

ls d DNSDomain

This command attempts to acquire all DNS resource records for the DNSDomain by requesting a zone transfer from the DNS server you connect to via the Nslookup console.

You can block this type of attack by restricting zone transfers in the properties of the DNS zone, as shown in Figure 15-2.

Via the Zone Transfers tab, you can restrict DNS zone transfers to the following:

• Servers listed on the Name Servers tab

  A zone transfer is possible only from DNS servers listed on the Name Servers tab of the DNS zone properties. If a DNS server requests a zone transfer and a DNS Name Server (NS) resource record does not exist in the DNS zone for the requesting IP address, the zone transfer is blocked. We recommend you use this option when you have numerous DNS servers that might request zone transfers.

• Specific IP addresses

  A zone transfer is possible only if the requesting DNS server s IP address is included in the list of approved DNS servers. If the requesting IP address is not included in the list, the zone transfer is blocked. We recommend you use this option only when a small number of secondary DNS servers exist for a zone.

  

  Figure 15-2. Restricting DNS zone transfers for the example.com zone

Implementing IPSec Between DNS Clients and DNS Servers

You can prevent unauthorized DNS clients from requesting DNS information from the internal DNS server by implementing IPSec to authorize connections to the DNS servers. With IPSec, a DNS client must successfully negotiate an IPSec security association (SA) with the DNS server before the DNS client can perform any DNS queries. If the DNS client is unable to establish an IPSec SA, the DNS client is blocked from all communications with the DNS server.

When configuring the IPSec filters for the DNS clients, you can choose from one of two IPSec protocols:

• Authentication Header (AH)

  Protects the DNS packets by requiring the DNS client to authenticate with DNS servers before communications can be established. AH also protects the DNS queries against modification and proves the source of the DNS queries. AH does not provide any encryption to the transmitted data, making DNS queries and responses subject to network inspection.

• Encapsulating Security Payload (ESP)

  Protects the DNS packets by encrypting them during the transmission between a DNS server and the DNS clients. In addition to encrypting the data, the ESP protocol signs the data payload, protecting it from modification.

  Be careful when applying IPSec filters to protect network traffic. Ensure that the IPSec filters describe all forms of network traffic in which the client or server participates. If you omit any forms of traffic from the listing of IPSec filters, the client will not be able to transmit data by using those forms. Be sure to include communications with DNS servers, domain controllers, and other essential network services in the IPSec filter listing.

Restricting DNS Traffic at the Firewall

A firewall can be used to restrict and protect the DNS traffic allowed to enter and exit the network. Depending on the network s DNS configuration, consider implementing the following packet filters at your firewall:

• Prevent external DNS clients from querying the internal DNS server.

  Ensure that the firewall does not allow connections from the Internet to the DNS server hosting the internal DNS zone data. You must prevent connections from the Internet to the internal DNS server s TCP port 53 (for zone transfers) and User Datagram Protocol (UDP) port 53 (for DNS queries).

• Prevent internal DNS clients from directly querying DNS servers on the Internet.

  You can configure the firewall to allow only approved hosts, such as the internal DNS servers, to query DNS servers on the Internet. The actual packet filter configuration will depend on whether you use forwarders or root hints when resolving DNS queries.

If you use forwarders, configure the firewall to allow DNS communications only to TCP port 53 and UDP port 53 of the DNS servers included in the Forwarders tab of the internal DNS servers. This ensures that internal DNS servers can forward DNS requests only to the approved DNS servers. If you use root hints, an internal DNS server can send a DNS query to any DNS server on the Internet, not just the root hint DNS servers. You must configure the firewall to allow all outbound queries sent from the IP addresses of the internal DNS servers sent to TCP port 53 or UDP port 53.

Limiting Management of DNS

Windows 2000 includes a custom domain local group, named DNSAdmins, in each domain in an Active Directory forest. The DNSAdmins group is delegated permission to fully manage DNS, without providing excess permissions to manage other services or objects in Active Directory.

You must ensure that membership in each DNSAdmins group is monitored to verify that unauthorized users or groups are not added. In addition, you should monitor membership in the local Administrators group, the Domain Admins group in each domain, the Enterprise Admins group, and the Enterprise Domain Controllers group. This is because members of these groups also have permissions to modify DNS configuration or Active Directory resource records.

Protecting the DNS Cache

If a DNS server receives a DNS query for a DNS resource record for which the DNS servers is not authoritative, the DNS server will check its DNS cache for a queried entry before it queries other DNS servers to resolve the DNS query. If an attacker is able to add unauthorized entries directly into the cache of the DNS server, he can redirect DNS clients to unauthorized hosts. This process is known as cache pollution.

To prevent corruption of the cache on a Windows 2000 DNS server, you can enable the Secure Cache Against Pollution option. This option is enabled in the Advanced tab of a DNS server s property sheet in the DNS console.

When enabled, the Secure Cache Against Pollution option inspects the response from another DNS server to determine whether any referenced names are attempts to pollute the DNS cache. For example, if a query is made for a Mail Exchange (MX) record for example.com and the response includes a referral record for host.contoso.com, the host.contoso.com response would not be cached because it is from a different namespace than was queried. This can result in a valid response not being cached. For example, contoso.com might be hosting the Internet e-mail services for example.com.