If you don't need to go through the entire iterative querying process but would simply like to see more detail about the queries going out of your system and the answers coming back, you can use the Set Debug or Set D2 options to get debug-level detail about the DNS query process. Figure 5 shows a sample query for www.windowsitpro.com. Also, by using Nslookup with the Set Type option (and specifying a domain name), you can quickly search for certain types of records within a domain by specifying their type—for example, MX (mail exchange) and NS (name servers) records.
For more information about Nslookup, see the Learning Path.
What AD Adds to the Mix
Once you've mastered the concepts of caching, iterative and recursive lookups, and troubleshooting and diagnosing DNS resolution problems across the Internet, you'll be able to tackle everything that AD adds to the table without too much difficulty. Integration between DNS and AD occurs on two levels: First, DNS is the primary mechanism with which systems on your network will find other hosts within the AD environment; second, DNS data—the listing of hosts that exist in a given domain, and their IP addresses—is replicated between DNS servers in your organization through AD multi-master replication. We've covered AD replication at length in these pages, so let's discuss the additional records that you'll typically find in DNS in an AD environment.
The records you'll find in an AD environment are dynamic registration records, which are automatically created by a client system (server or workstation) within AD and contain the system's host name and IP address. The DHCP client service on a workstation or server performs the registration process when the service starts up— even if you're using a manually assigned address. In its IP Properties, the DHCP client service will register its address with the DNS servers that it's configured to use. If you have certain network interfaces that are designed for specific purposes (e.g., a dedicated tape backup network) and don't respond to client requests coming in on those interfaces, this automatic registration process can present DNS name-resolution problems on the network.
For example, these specific adapters could be registered with IP addresses within DNS when you don't want those IP addresses handed out as possible response answers. If you find yourself in this situation, you can disable the registration of an interface by editing the advanced DNS properties for that interface and clearing the Register this connection's addresses in DNS check box, which Figure 6 shows. Otherwise, Windows will generally attempt to register every interface it can with DNS.
In addition to registering these host records (i.e., "A" records) automatically, Windows registers an additional record type—server records ("SRV" records)—for DCs. SRV records determine how systems participate within AD to handle authentication tasks. SRV records aren't specific to AD; rather, they're a standard DNS record type that defines the services available within a domain, the hosts on which to find those services, and the ports and protocols to use. Much as mail-exchange records ("MX" records) specify that SMTP services can be found at a specific port (i.e., port 25) of a certain server, SRV records can provide a referral to any type of service on any system. For example, an SRV record that would define the example.com Web site might look like
_http._tcp.example.com
SRV 0 0 80 www.example.com
We can intuit a few things from this example—namely, that a TCP service known as HTTP is available for the example.com domain and that it can be found on port 80 of the host named www.example.com. In an AD environment, a DC registers four types of SRV records with the DNS servers it's configured to use:
_ldap._tcp.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.example.com
SRV 0 0 88 dc.example.com
_ldap._tcp.dc._msdcs.example.com
SRV 0 0 389 dc.example.com
_kerberos._tcp.dc._msdcs.example.com
SRV 0 0 88 dc.example.com
These records let AD-enabled clients know where to find the necessary LDAP and Kerberos services necessary for the example .com domain to find other AD resources and authenticate to those resources. These four sample SRV records effectively point the ADaware clients to the dc.example.com system (a hypothetical DC for example.com) for all of their authentication needs.
As part of any AD-and DNS-related diagnosis process, you should make sure that these records are available through the MMC DNS snap-in for the DNS servers in your organization. You should also be able to look them up from client systems by using the Nslookup utility.
Time for a Brush-up?
After brushing up on Nslookup, I quickly solved the problem on my network—a cache error involving my ISP and the data that should have been returned for a specific DNS query. After I determined the root cause of the problem—by performing the complete iterative lookup process myself—I was able to quickly implement an alternative solution for resolving public DNS names while my ISP worked on solving its problems. The problem was solved quickly, and my clients were back to having fully functional name resolution again. With a good understanding of how DNS works, as well as a strong set of tools with which to troubleshoot it when it's misbehaving, you can quickly resolve many DNS problems.
Douglas Toombs (help@toombs.us) is a contributing editor for Windows IT Pro and the author of Keeping Your Business Safe from Attack: Monitoring and Managing Your Network Security (Windows IT Pro eBooks).
End of Article
Register
