Manage Learn to apply best practices and optimize your operations.

DNS best practices: Making AD rock-solid

Some consider DNS to be the heart of Active Directory, and like any heart, it is important to keep it healthy. Expert Gary Olsen offers his set of best practices for maintaining a secure and properly configured DNS.

Anyone familiar with Active Directory understands the importance that the domain name system (DNS) has on all aspects...

of proper AD operation.

The reason is simple. Any time a client makes a request for a domain service, such as authentication, it must find a domain controller to service that request. The Netlogon service on the client finds a name server, which then finds the appropriate SRV record of a DC that can service the request. The DC's information is then returned to the client, which sends the request to the DC. This process is used for tasks such as simple user logon, Outlook requests for Global Address Lookups, access to resources such as file shares and printers as well as domain controller replication.

Thus, AD replication depends heavily on DNS, and FRS depends on AD replication to deliver Group Policy and its associated controls and security. For these reasons, DNS is indeed the heart of Active Directory, and ensuring that it is properly configured and healthy is extremely important.

Microsoft has published its own DNS best practices, but the list only includes a few recommendations and is insufficient to cover the many issues we see in DNS today. Therefore, through my experience with resolving DNS issues for Active Directory, I've identified my own set of best practices. They are divided up into four areas: client configuration, server configuration, DNS configuration and monitoring. While I could easily write an article on each of these areas separately, here I have identified some significant aspects of each one to provide a simple list of recommendations.

Note: For clarity, I use the term "name server" when talking about name resolution and "DNS server" when referring to a physical server or verbiage in a Windows UI or documentation.

Client configuration

  • TCP/IP settings -- This is one of the key elements of client access to resources. It's a simple thing that many administrators make complicated.
    * Each DNS client (workstation, server or DC) should point to its closest name server for its domain as the preferred DNS server. You can add name servers as needed, but they must all be name servers for the client's domain. Figure 1 shows the TCP/IP properties screen where this is defined. It is defined the same way for workstations, servers and domain controllers.
    Figure 1
    * Do not configure your ISP's DNS server as an "alternate" DNS server. I have seen many configurations where the DNS server for a company's ISP provider was added here. I have only seen one case where putting another DNS server in a client's TCP/IP settings was justified. Your client can't authenticate against it, it can't find internal resources and that name server won't register the A record.

    * You can add more than two additional DNS servers in the DNS tab of Advanced TCP/IP properties, as seen in Figure 2.

    Figure 2

Server configuration

Note: I further detailed server configuration in a January article, Configurating DNS server properties.

  • Static IP address -- It goes without saying that a DNS server should have a static IP address, just like a domain controller. You don't want DNS breaking when Dynamic Host Configuration Protocol (DHCP) gives it a new address.
  • Do not define custom Root Hints -- This can cause a lot of headaches if you enter it incorrectly and you forget about it. It's not a common area to look for when troubleshooting a problem, and it might take a while to find it if it breaks.
  • Server location -- There are a number of considerations regarding the quantity and location of name servers. I will cover this further in Active Directory DNS best practices, part 2.
  • Don't change IP address if possible -- This seems terribly obvious, but sometimes it happens. Companies that acquire a new block of addresses, or do a re-addressing initiative, might find it necessary to change a DNS server's address. While you probably push the DNS information to workstations via DHCP, there will be a lot of servers and DCs that will have to be changed manually. Don't forget delegation records, either. If the address of a name server that has a child zone delegation is changed, make sure you change the delegation record in the root zone. I've seen the result when it's not done, and it takes a while to figure out.
  • If the DNS server dies or has to be replaced, use the old server's IP address -- It will save you time and reduce help desk calls.
  • Managing forwarders -- Make sure the IP addresses to the name servers you are forwarding to (internal or external) are correct. If you have several admins with access to this, you might find inappropriate or erroneous entries made, which can make lookups inefficient.
  • Avoid the Disable Recursion option on the Forwarders tab of DNS server properties -- Do not check this box if you use forwarders. Enabling this option will cause the forwarders to be ignored and name resolution will not be attempted outside the zones hosted by that name server.
  • Conditional forwarding -- Investigate this feature on the Forwarders tab of DNS server properties. It can have a positive effect on cross-domain lookups, especially in a multiple domain environment. (Again, check out my article on DNS server configuration for more details.


OK, so the question is, if you do a good job and have an efficient DNS design, why should you need to worry about it? Well, things break. Servers go down, addresses change and administrators make mistakes. It is important to monitor DNS just like you monitor any other AD component.

The event log is a good start. DNS errors will be reported in the system, DNS and directory services log. In fact, I find very few actual name resolution events in the DNS log. Those tend to end up in the system or directory services log. DNS errors are often added as a description to another event rather than having its own separate event. For instance, you will see "DNS lookup failure" in the description of a variety of other events, including the infamous 1311 in the directory services log. Basically, the important thing to remember is to be proactive in monitoring DNS.

There are a couple of fairly simple (and cheap) ways you can monitor DNS:

  • DCDiag /Test:DNS /e /v >file.txt -- This was detailed in my article New tool can help assess your DNS environment. It evaluates each DNS server for authentication, basic connectivity, forwarding, delegation, and dynamic updates being enabled, and then reports the results in a neat, clean table at the end of the report. It also provides details of each server evaluation, including any errors it found. I use this in every AD troubleshooting case I work on so I can see if DNS is healthy.

  • Verbose logging -- You can turn up verbose logging on name resolution using the registry at HKLM\system\CCS\services\NTDS\Diagnostics. This will add additional events to the event log for diagnosing DNS errors.

In my next article I'll complete my list of best practices by discussing the many issues regarding the DNS structure itself. They include delegation, forwarding, using Active Directory Integrated Zones, delegating the _msdcs zone in multiple domain environments and placement of name servers in the forest.

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.

Dig Deeper on Windows systems and network management