DNS in an Active Directory Environment

DNS is inseparable from Active Directory. In fact, the two are often confused for one another because of the similarities in their logical structures.

Active Directory uses a hierarchical LDAP-compliant structure that was designed to map into the DNS hierarchy, hence the similarities. In addition, Active Directory uses DNS for all internal lookups, from client logins to global catalog lookups. Subsequently, strong consideration into how DNS integrates with Active Directory is required for those considering deploying or upgrading AD.

Impact of DNS on Active Directory

As any Windows 2000 administrator can attest, problems with DNS can spell disaster for an Active Directory environment. Because all servers and clients are constantly performing lookups on one another, a break in name -resolution service can severely affect Active Directory activity.

For this and other reasons, installing a redundant DNS infrastructure in any Active Directory implementation is strongly recommended. Even smaller environments should consider duplication of the primary DNS zone, and nearly as much emphasis as is put into protecting the global catalog AD index should be put into protecting DNS.

Security considerations for the DNS database should not be taken for granted. Secure updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a domain controller can also help to secure DNS. In addition, limiting administrative access to DNS will help to mitigate problems with unauthorized "monkeying around" with DNS.

Active Directory in Non-Microsoft DNS Implementations

Active Directory was specifically written to be able to co-exist and, in fact, use a non-Microsoft DNS implementation as long as that implementation supports active updates and SRV records. For example, AD will function in all versions of Unix BIND 8.1.2 or later. With this point in mind, however, it is still recommended that an organization with a significant investment in Microsoft technologies consider hosting Active Directory DNS on Windows Server 2003 systems because functionality enhancements provide for the best fit in these situations.

For environments that use older versions of DNS or are not able (or willing) to host Active Directory clients directly in their databases, Active Directory DNS can simply be delegated to a separate zone in which it can be authoritative . The Windows Server 2003 systems can simply set up forwarders to the foreign DNS implementations to provide for resolution of resources in the original zone.

Using Secondary Zones in an AD Environment

Certain situations in Active Directory require the use of secondary zones to handle specific name resolution. For example, in peer-root domain models, where two separate trees form different namespaces within the same forest, secondaries of each DNS root are required to maintain proper forestwide synchronization.

Because each tree in a peer-root model is composed of independent domains that might not have security privileges in the other domains, a mechanism will need to be in place to allow lookups to occur between the two trees. The creation of secondary zones in each DNS environment will provide a solution to this scenario, as illustrated in Figure 13.2.

Figure 13.2. Peer-root domain DNS secondary zones.

Specifying SRV Records and Site Resolution in DNS

All Active Directory clients use DNS for any type of domain-based lookups. Logins, for example, require lookups into the Active Directory for specific SRV records that indicate the location of domain controllers and global catalog servers. Windows Server 2003, as previously mentioned, divides the location of the SRV records into a separate zone, which is replicated to all domain controllers that have DNS installed on them.

Subdomains for each site are created in this zone; they indicate which resource is available in those specific sites. In a nutshell , if an SRV record in the specific site subdomain is incorrect, or another server from a different site is listed, all clients in that site are forced to authenticate in other sites. This concept is important because a common problem is that when Active Directory sites are created before they are populated with servers, an SRV record from the hub location is added to that site subdomain in DNS. When a new server is added to those sites, their SRV records join the other SRV records that were placed there when the site was created. These records are not automatically deleted, and they consequently direct clients to servers across slow WAN links, often making login times very slow.

In addition to the site containers, the root of these containers contains a list of all domain controllers in a specific domain, as shown in Figure 13.3. These lists are used for name resolution when a particular site server does not respond. If a site domain controller is down, clients randomly choose a domain controller in this site. It is therefore important to make sure that the only entries in this location are servers in fast-connected hub sites. Proper grooming of these SRV records and placement of servers into their proper site subdomains will do wonders for client login times.

Figure 13.3. Site-level SRV records.