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.
Client configuration
Figure 1
[IMAGE]Figure 2
[IMAGE]
Server con...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
figuration
Note: I further detailed server configuration in a January article, Configurating DNS server properties.
Monitoring
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:
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 Windows Server-File Systems.
