When working with the domain name system (DNS) for Active Directory, there are several key components to be aware of regarding client configuration, server configuration and monitoring. Another aspect that should not be overlooked, however, involves DNS structure and design.
When designing the DNS structure, keep in mind certain principles and practices that will affect the overall name resolution performance in the network. DNS structures that are patched together or not well thought out will work, but they have pockets of failure that will affect AD performance. That is why adherence to best practices in the DNS structure is extremely important in creating an efficient and productive Active Directory.
Know the basic principles
Here are the main points to keep in mind when designing the DNS structure:
- Keep it simple.
DNS is inherently very simple, so why complicate it? Of course, there are many complexities you can add such as the use of secondary zones, putting DNS on every DC, tweaking special settings, custom root hints, and so forth. While some of these additions could certainly be important in your environment, it's important to evaluate each one for the added value versus the increased manageability (and potential for breaking something) that will come along with it.
Many times, admins will try to fix a poorly designed DNS structure by tweaking parameters, adding additional secondary zones and other tricks. If you have to keep doing these things to make DNS work, then step back and take a look to see the whole picture. With dynamic registration, Microsoft DNS is quite resilient and can easily be rebuilt in most cases. Remember, DNS is the heart of AD. Make sure it is designed efficiently.
- Islands of resolution.
Microsoft's KB 275278 describes an old Windows 2000 issue. In this scenario, DNS servers pointing to themselves for DNS may register CName records on random DNS servers, and cause inconsistency in replication. The KB
recommends selecting a single DNS server in the domain as what I will refer to as the "primary" server. It then instructs you to point that server's preferred DNS server to itself. According to the article, all other DNS servers will point their preferred DNS server to that primary as well. They can also point to themselves and other DNS servers as "additional" DNS servers. Improvements were made in Windows 2003, and in Hotfix 824333 that allow more tolerance for DNS servers to point to themselves for name resolution.
Related DNS articles DNS best practices: Making AD rock-solid
Configuring DNS server properties
Note: These KBs mainly refer to problems related to AD replication.However, in my experience, the method of having each DNS server pointing to itself causes more problems than just AD replication issues. That is why I agree with the recommendation that has all DNS servers pointing to a single name server for preferred DNS.
I recall one admin who called about a Systems Management Server (SMS) issue. In the process of troubleshooting, I noticed his DNS servers pointed to themselves for DNS. After a long discussion, I finally convinced him to have the DNS servers point to a single primary. He called back the following day and reported that his clients had never had better name resolution performance. I've seen that scenario many times and, even today, as a general rule, I always recommend pointing all DNS servers to a single primary as the "preferred DNS server."
- Use Active Directory integrated zones.
This is a great implementation of a domain name system, and it's obviously on Microsoft's best practice list. Its advantages include:→ Zone transfers take place within AD replication, eliminating the need for what are often problematic zone transfers for secondary zones.
→ You can still host secondary copies of the zone in remote sites.
→ Windows Server 2003 offers efficient replication options, so DNS records are only replicated to DCs that are DNS servers.
→ They eliminate a single point of failure that a standard primary zone has. Since the AD holds the DNS records, you can lose all of your DNS servers and still retain the DNS records for easy restoration to a new DNS server. This eliminates the messy job of backing up the zone file and importing it back to a standard primary name server.
→ It's easy to fix when it occasionally breaks or becomes corrupt (see my article on this, Active Directory-integrated DNS zones and the case of the disappearing zones!)
- Each domain should have its own DNS delegation.
In a parent/child domain environment, there should be an authoritative name server in each child domain. All clients (workstations, servers, DCs) in that domain should point to this name server for a DNS. To make this work, you must create a delegation for the child domain in the root domain and add the IP address of all DNS servers in the child domain to that delegation. In addition, in the child domain's name servers, they must forward back to the parent's DNS servers.
You can find the principles of forwarding and delegation in any good DNS book or go to Microsoft's DNS white paper.
I often find that this is only partially implemented. For example, the delegation record is created, but the admin forgets to forward back to the root domain. It's amazing how long this situation can exist without raising any flags. In fact, I've seen cases where they start adding secondary zones and other tricks to patch it together, or sometimes they simply live with it.
Here are the benefits of configuring each domain to have its own domain name system delegation:* Partitioning of DNS records by domain -- It allows a more localized storage of DNS records, rather than storing them all in root domain name servers.
* It allows easy delegation of administration -- Administration of DNS records for each domain rests with domain administrators and their delegates, rather than admins of the root domain.
* It makes it easier to troubleshoot -- Problems are isolated by domain.
- Delegate the _msdcs zone in a multiple domain environment.
This zone holds important records such as CName (alias) records used for AD replication and global catalog (GC) records. In a multiple domain forest, these two record types only exist in the _msdcs zone that is in the forest root domain. Other domains (even if they are not child domains to the forest root) do not contain these records. This means that DCs for any other domain in the forest must go back to the name servers in the forest root domain to resolve CName records for replication. The same goes for clients looking for a GC for authentication, Outlook Global Address List lookups, etc. If they can't get to those name servers, then it all breaks. Delegating the root zone's _msdcs zone to child domain name servers will put the GC and CName records closer to the requestors and increase the efficiency of name resolution.
- Name servers in remote sites.
This is a tricky one. As I noted previously, many environments make each DC a DNS server (for ADI zones) and make sure that there is a name server in each site. In sites that don't have a DC, you can install a DNS on a member server and make a secondary copy of the zone.
That said, there are large AD forests that use very few DNS servers. Hewlett-Packard, for example, has a root domain, HP.com, and three child domains: Americas, EMEA and AsiaPacific. They have delegated zones for the child domains from the root. For each of these geographical zones, there are only about three DNS name servers -- not one per site, not one per DC. Of course this depends very much on your network infrastructure. You don't want to do this if you have poorly connected or unreliable network links. However, you could use three name servers for the general population, and then add name servers in those poorly connected sites as needed.
It is important to review your DNS structure. In times of change and growth, mistakes can be made, often unknowingly. Using the DCDiag tool is a good quick health check, and reviewing event logs for DNS-related errors via MOM or other tools is also helpful. However, I highly recommend a high-level review of the DNS structure by comparing it to best practices to proactively ensure that Active Directory is running smoothly.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.