When DNS name resolution stops working, your Microsoft Active Directory (AD) environment has problems. DNS is the bedrock of your environment, and without name resolution, operations may be interrupted or grind to a halt. Possibly a name resolution issue has built up over time due to a slow migration away from a sound DNS tree hierarchy design. This could have happened as a result of decisions made by segmented groups where an immediate functional need was required but enterprise DNS design consideration fell to the wayside. Here are some key tips and troubleshooting tools to help you avoid or resolve DNS problems.
Tip 1: The DNS namespace should reflect a contiguous tree hierarchy
The Internet DNS namespace has a tree hierarchy (by design), and administration of this is delegated to DNS administrators responsible for various branches of the DNS namespace (IETF RFC 1034, RFC 1032). Like their Internet counterparts, intranet DNS admins should follow hierarchical tree design. Whenever a non-contiguous or disjoint namespace is encountered in an intranet environment, complexity will ensue in the form of the addition of conditional forwarders, stub zones, and/or secondary zones.
Take the scenario of a company acquisition, where each company has two separate, independent namespaces that must be consolidated in functionality using Windows Server trusts. A suggested approach is to create a secure VPN between both company environments at the root of each separate, continuous namespace. Use conditional forwarders to direct name queries across the VPN to the namespace on the opposite side of the VPN tunnel, as Figure 1 shows.
Figure 1: Using conditional forwarding across separate DNS namespaces on an intranet
Any queries that do not meet conditional forwarder criteria would simply be forwarded up to the ISP's DNS servers. DNS servers configured for conditional forwarding located in the root level of one contiguous namespace will forward queries to a specific DNS server located in the other contiguous namespace. A cache of namespace information is amassed on this DNS server, and the need for recursion is decreased.
Instead of using conditional forwarders, some admins choose to implement stub zones on the DNS servers in top-level intranet domains such as domain1.local and domainA.local. Stub zones contain only enough record information to be able to determine the authoritative DNS servers for the subordinate zone and are more of a consideration when zones are not stored in AD. Stub zones are a consideration when a DNS server in a parent zone needs to be kept aware of the authoritative DNS servers in the child zone. Stub zones increase complexity because when a stub zone replies to a query for a name, all authoritative DNS servers in the domain are provided in the DNS response. The goal should be to have a DNS infrastructure design that is functional and straightforward to troubleshoot.
Tip 2: Understand where DNS information is stored
DNS zone data can be stored in the AD information tree or in the file system in c:\%systemroot%\system32\dns. I strongly recommend that you store zone information in AD, then replicate this zone information either to every DNS server in the domain (DomainDNSZones) or possibly in the forest (ForestDNSZones). Storing DNS information on every DNS server in the domain, then forwarding upstream to the parent zone is an optimal choice. DNS forwarding would be set up so that DNS servers in child1.domain1.local and child2.domain1.local forward to DNS servers in parent domain1.local. In the parent domain, there would be delegation to each child domain. (For additional information about DNS zone location, see my article "Chasing the DNS Zone Location Problem".)
Tip 3: Identify whether the DNS problem is a name-registration or name-resolution problem
To resolve a name, the name must be registered in a zone on a DNS server. In a Windows environment, different services register different records. In Windows 7, Windows Vista, Windows Server 2008 R2, and Server 2008, the DNS client service registers A and PTR records. In Windows XP and Windows Server 2003, the DHCP client service registers A and PTR records. The registration interval is 24 hours, except for when the DHCP server is doing the registering; in this case, the registration should take place when the DHCP client's lease is renewed.
In Server 2008 R2, Server 2008, and Windows 2003, the Netlogon service is responsible for the registration of some additional records. A log of the records registered by the Netlogon service is located at %SystemRoot%\System32\Config\Netlogon.dns. Domain controllers (DCs) dynamically register 15 to 30 SRV records every hour in Server 2008, whereas in Windows 2003 the registration by Netlogon is every 24 hours.
In Server 2008, the Cluster service registers the cluster network name resource when the resource comes online. The record is updated at least once every 24 hours. The setting RegisterAllProvidersIP can be used to determine whether all IP addresses for the network name resource are registered in DNS. (For more information, see the Microsoft article "Description of what to consider when you deploy Windows Server 2008 failover cluster nodes on different, routed subnets".)
The problem is a DNS registration issue. If DNS records are not present in the DNS console, use ADSI Edit to verify that the records are not simply being displayed in the DNS console GUI or in AD. Verify record existence in AD by following the steps in the article "Event ID 4515 is logged in the DNS Server log in Windows Server 2003". If the records are not present, install Microsoft's Network Monitor on the machine performing the DNS registration and take a network trace while attempting to register the A, PTR, or SRV records. To initiate A and PTR record registration, issue this command:
ipconfig /registerdns
For SRV record registration, issue this command:
c:\net stop netlogon && net start netlogon
Stop the network trace and filter on DNS traffic. If no registration traffic is present in the network trace, focus on whether the service responsible for the registration (DHCP client, DNS client, Netlogon, Cluster) is running, and check the event logs. (If you're still stuck at this point, it may be time to call Microsoft Support.)
The problem is a DNS resolution issue. If the technical issue is not related to DNS record registration, change the troubleshooting approach and investigate DNS name resolution. First, ping the Fully Qualified Domain Name (FQDN) of the target and determine success or failure. If the failure is by name and not by IP address, verify that the DNS server settings are properly configured in the TCP/IP properties of the machine initiating the query. Next, start a network trace and clear the resolver cache by issuing this command:
c:\ipconfig /flushdns
Now ping the target by FQDN (e.g., ping server.domain1.local). Stop the network trace and determine whether there is an outbound DNS query and/or an inbound DNS response. The goal here is to determine whether the issue is with getting a query to the DNS server or if the DNS server gets the query and either doesn't respond or the response fails to reach the DNS query initiator.
Tip 4: Use DNS diagnostic tools
To assist you in troubleshooting DNS issues, make sure you have these tools in your DNS toolkit: DNSLint, DCDiag, and NSlookup.
DNSLint. The DNSLint utility has three functional tests, all of which output results to an HTML report. The test are for "lame delegation", the DNS records required for AD replication to succeed, and verifying a user-defined set of DNS records on multiple DNS servers. Specify /d on the dnslint command to perform the domain name test and provide results that can help in diagnosing lame delegation. Specify /s to indicate the IP address of the DNS server for the DNS server authoritative for the domain. Specify /ad to determine whether the DNS record needing AD forest replication is resolvable. (For more information, see "Description of the DNSLint utility".)
DCDiag. You can run the dcdiag command using the option /test:DNS. Test options include a DNS basic test and tests for forwarders and root hints, delegation, DNS dynamic updates, DNS record registration, and Internet name testing.
Test the health of a DC:
DCDIAG /TEST:DNS /v /s:/f:
Test the health of all forest DCs:
DCDIAG /TEST:DNS /f /e /f:
Test the DC's ability to register the DC Locator DNS records:
DCDIAG /TEST:RegisterInDNS /DnsDomain:/v /f:
(In the previous commands, /v specifies verbose output, /s means run local, /f means direct output to file, and /e means test all servers.)
In Windows 2003 SP2, use the DCDiag utility included with SP2, as described in support.microsoft.com/kb/926027. In Server 2008 and Server 2008 R2, install DCDiag by navigating to Server Manager, Features, Add Features, Remote Server Administration Tools, Role Administration Tools, Select DNS Server Tools, Next, Install.
NSlookup. This is a well-known command for DNS troubleshooting. View NSlookup syntax variations by running NSlookup from a command prompt, then issuing the command help. Keep in mind that NSlookup has its own built-in stub resolver in the executable and does not use the OS's resolver.
Tip 5: Microsoft DNS best practices
Check your Server 2008 R2 DNS environment's heath by using the Microsoft Best Practices Analyzer (BPA) included in Server 2008 R2. Two variations of the tool exist: one for best practices for DNS configuration, and the second for best practices for DNS operation. BPA is helpful tool for scanning your Server 2008 R2 DNS environment and investigating potential DNS configuration issues.
To open BPA, follow these steps:
- Go to Start, Administrative Tools, and click Server Manager.
- In the tree pane, open Roles, then select the role for which you want to open BPA.
- In the details pane, open the Summary section, then open the Best Practices Analyzer area.
For more information about BPA, see the Best Practices Analyzer page.
For Windows Server 2008, a DNS model exists for the Microsoft Baseline Configuration Analyzer (MBCA). The MBCA tool compares DNS server configurations against DNS best practices outlined in the MBCA 2.0 DNS model. You can download MBCA here.
Healthy DNS, Healthy AD
A Windows AD environment can experience a variety of problems when name resolution fails. Determine whether the problem is localized to a machine, subnet, or network. Next, determine whether the problem is with DNS name registration or with DNS name resolution. Finally, use Microsoft tools when needed, both for troubleshooting and keeping your DNS environment healthy.
Boyd Gerber ([email protected]) is a support escalation engineer with Microsoft Networking Escalation. His DNS industry experience is with DNS support and DNS development teams. He has a graduate degree in software engineering from the University of Texas at Austin.
