Microsoft Windows Server 2003 Insider Solutions
| Much has been written about the complexity of DNS, and even more misconceptions have been written about it. In truth, however, DNS structure is logical, so you can easily troubleshoot it, if you use the proper tools and techniques. A good grasp of these tools and their functionality is a must for proper name -resolution troubleshooting with DNS. Using the DNS Event Viewer to Diagnose Problems
As any good administrator knows , the Event Viewer is the first place to look for any type of troubleshooting. Windows Server 2003 makes it even more straightforward to use because DNS Events compiled from the Event Viewer are immediately accessible from the DNS MMC console. Parsing this set of logs can help you to troubleshoot DNS replication issues and query problems. For more advanced Event Log diagnosis, you can turn on Debug Logging on a per-server basis. It is recommended that you turn on this functionality only as required, however, because log files can fill up fast with debugging turned on. To enable Debug Logging, follow these steps:
It is recommended that you turn off these settings after the troubleshooting is complete. Using Performance Monitor to Monitor DNS
Performance Monitor is a built-in, often-overlooked utility that allows for a great deal of insight into issues in a network. In regards to DNS, many critical DNS counters can be monitored relating to queries, zone transfers, memory use, and other important factors. Client-Side Cache and HOST Resolution Problems
Windows 2000 and later clients have a built-in client cache for name resolution that caches all information retrieved from name servers. When requesting lookups, the client resolver parses this cache first, before contacting the name server. Items remain in this cache until the TTL expires , the machine is rebooted, or the cache is flushed. In cases where erroneous information has been entered into the client cache, you can flush it by typing ipconfig /flushdns at the command prompt. By default, all clients have a file named HOSTS that provides for a simple line-by line resolution of names to IP addresses. This file is normally located in \%systemroot%\system32\drivers\etc. Problems can occur when these manual entries conflict with DNS, and it is therefore wise to ensure that there are not conflicts with this HOSTS file and the DNS database when troubleshooting. Using the NSLOOKUP Command-Line Utility
The NSLOOKUP command-line utility is perhaps the most useful tool for DNS client troubleshooting. Its functionality is basic, but the information that you obtain can do wonders for helping you to understand DNS problems. NSLOOKUP, in its most basic operation, contacts the default DNS server of a client and attempts to resolve a name that is input. For example, to test a lookup on www.companyabc.com , type nslookup www.companyabc.com at the command prompt. Different query types can be also input into NSLOOKUP. For example, you can create simple queries to view the MX and SOA records associated with a specific domain by following these steps, which are illustrated in Figure 13.20: Figure 13.20. NSLOOKUP on an MX record.
NSLOOKUP's functionality is not limited to these simple lookups. Performing an nslookup /? lists the many functions it is capable of. NSLOOKUP is a tool of choice for many name-resolution problems and is a must in any troubleshooter's arsenal. Using the IPCONFIG Command-Line Utility
Another important tool for DNS resolution problems is the IPCONFIG utility, the same utility used for common TCP/IP issues. There are several key functions that IPCONFIG offers in regards to DNS. These functions can be invoked from the command prompt with the right flag, detailed as follows :
These Three Flags These three flags, as well as a few others, are available only in Windows 2000 or later clients. Previous clients such as NT 4.0 were limited to more basic functionality with IPCONFIG, and other clients such as Win9x clients used a different utility known as WINIPCFG. As with any utility, you can unearth more advanced functionality by invoking the utility with a ? flag ( ipconfig /? ).
Using the TRACERT Command-Line Utility
The TRACERT utility is a valuable resource that gives you an idea of the path that a DNS query takes when being sent over a network. By directing TRACERT at www.microsoft.com , for example, you can get an idea of how many routers and DNS servers the packet is crossing . The way that TRACERT works is simple but actually quite interesting. A DNS query that has a TTL of 1 is sent out. Because all routers are supposed to drop the TTL by 1 on each packet that they process, this means that the first router will refuse to forward the packet and send that refusal back to the originator. The originating machine then increments the TTL by 1 and resends the packet. This time the packet will make it past the first router and get refused by the second. This process continues until the destination is met, as illustrated in Figure 13.21. Needless to say, using this command-line utility is a simple yet effective way of viewing the path that a DNS query takes as it crosses the Internet. Figure 13.21. Sample TRACERT results.
Using the DNSCMD Command-Line Utility
The DNSCMD utility is essentially a command-line version of the MMC DNS console. Installed as part of the Windows Server 2003 Support tools, this utility enables you to create zones, modify records, and perform other vital administrative functions. To install the support tools, run the support tools setup from the Windows Server 2003 CD (located in the \support\tools directory). You can view the full functionality of this utility by typing DNSCMD /? at the command line, as illustrated in Figure 13.22. Figure 13.22. DNSCMD command-line options.
|