Much
has been written about the complexity of DNS, and even more confusion
and 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 will know, Event Viewer is the first place to look when
troubleshooting. Windows Server 2008 R2 makes it even more
straightforward to use because DNS events compiled from Event Viewer are
immediately accessible from the DNS Manager Console. Parsing this set
of logs can help you troubleshoot DNS replication issues, query
problems, and other issues.
For more advanced event log
diagnosis, you can turn on Debug Logging on a per-server basis. It is
recommended that this functionality be turned on only as required,
however, as this can affect server performance and the log files can
fill up fast. To enable Debug Logging, follow these steps:
1. | |
2. | Expand the Roles, DNS Server, DNS nodes, and then select the DNS server name.
|
3. | Right-click the server name and choose Properties.
|
4. | Select the Debug Logging tab.
|
5. | Check the Log Packets for Debugging check box.
|
6. | Configure any additional settings as required, and click OK.
|
By default, the log file is named dns.log and is saved in the c:\windows\system32\dns\directory. Listing 1 shows the debug of the DNS server dc1.companyabc.com of a lookup of the record www.cco.com
from the server at 192.168.3.201. You can see from the log that the
request was forwarded to the DNS server at 192.168.2.5 and that the
results were then sent to the requesting server at 192.168.3.201.
Listing 1. DNS Log File
9/27/2009 11:52:03 AM 0388 PACKET 0000000002425D80 UDP Rcv 192.168.3.201 0002
Q [0001 D NOERROR] A (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 0000000002425D80 UDP Snd 192.168.3.201 0002 R
Q [8385 A DR NXDOMAIN] A (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 000000000381E940 UDP Rcv 192.168.3.201 0003
Q [0001 D NOERROR] AAAA (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 000000000381E940 UDP Snd 192.168.3.201 0003 R
Q [8385 A DR NXDOMAIN] AAAA (3)www(3)cco(3)com(10)companyabc(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 00000000032FF460 UDP Rcv 192.168.3.201 0004
Q [0001 D NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:03 AM 0388 PACKET 0000000003C74A00 UDP Snd 192.168.2.5 95b5
Q [1001 D NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000003138020 UDP Rcv 192.168.2.5 95b5 R
Q [8081 DR NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 00000000032FF460 UDP Snd 192.168.3.201 0004 R
Q [8081 DR NOERROR] A (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000002425D80 UDP Rcv 192.168.3.201 0005
Q [0001 D NOERROR] AAAA (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 00000000032FF460 UDP Snd 192.168.2.5 1240
Q [1001 D NOERROR] AAAA (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000002F30BE0 UDP Rcv 192.168.2.5 1240 R
Q [8081 DR NOERROR] AAAA (3)www(3)cco(3)com(0)
9/27/2009 11:52:04 AM 0388 PACKET 0000000002425D80 UDP Snd 192.168.3.201 0005 R
Q [8081 DR NOERROR] AAAA (3)www(3)cco(3)com(0)
|
The DNS log can be very
detailed and tedious to read, but provides a wealth of information about
exactly what the DNS server is doing. You can get even more detail by
selecting the Details check box on the Debug Logging tab, which also
enables you to see the data that
was returned. Logging does add significantly to the load of the DNS
server, so it should only be enabled when troubleshooting and disabled
immediately afterwards.
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 regard to DNS, many critical DNS
counters can be monitored relating to queries, zone transfers, memory
utilization, and other important factors.
Client-Side Cache and HOST Resolution Problems
Windows 2000 and higher
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, it can be flushed 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 obtained can do wonders
for helping 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 inputted. For example, to test a lookup on www.companyabc.com, type nslookup www.companyabc.com
at the command prompt. Different query types can also be 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 1:
1. | Open a command-prompt instance by choosing Start, All Programs, Accessories, Command Prompt.
|
2. | Type nslookup and press Enter.
|
3. | Type set query=mx and press Enter.
|
4. | Type <domainname> and press Enter.
|
5. | Type set query=soa and press Enter.
|
6. | Type <domainname> and press Enter.
|
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 regard to DNS. These functions can be
invoked from the command prompt with the right parameter, detailed as
follows:
ipconfig /flushdns—If you experience problems with the client-side cache, the cache itself can be “flushed” through the invocation of the flushdns
flag. This removes all previously cached queries that a client might be
storing and is particularly useful if a server name has just changed IP
addresses and particular clients have trouble connecting to it.
ipconfig /registerdns—The registerdns flag forces the client to dynamically reregister itself in DNS, if the particular zone supports dynamic updates.
ipconfig /displaydns—An interesting but not well-known parameter is displaydns.
This flag displays the contents of the client-side cache and is useful
for troubleshooting specific issues with individual records.
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.
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.
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 2008 R2 DNS Server role, this utility allows
administrators to create zones, modify records, and perform other vital
administrative functions via the command line. You can view the full
functionality of this utility by typing DNSCMD /? at the command line,
as illustrated in Listing 2.
Listing 2. DNSCMD Command Options
Usage: DnsCmd <ServerName> <Command> [<Command Parameters>]
<ServerName>:
IP address or host name — remote or local DNS server
. — DNS server on local machine
<Command>:
/Info — Get server information
/Config — Reset server or zone configuration
/EnumZones — Enumerate zones
/Statistics — Query/clear server statistics data
/ClearCache — Clear DNS server cache
/WriteBackFiles — Write back all zone or root-hint datafile(s)
/StartScavenging — Initiates server scavenging
/IpValidate — Validate remote DNS servers
/ResetListenAddresses — Set server IP address(es) to serve DNS requests
/ResetForwarders — Set DNS servers to forward recursive queries to
/ZoneInfo — View zone information
/ZoneAdd — Create a new zone on the DNS server
/ZoneDelete — Delete a zone from DNS server or DS
/ZonePause — Pause a zone
/ZoneResume — Resume a zone
/ZoneReload — Reload zone from its database (file or DS)
/ZoneWriteBack — Write back zone to file
/ZoneRefresh — Force refresh of secondary zone from master
/ZoneUpdateFromDs — Update a DS integrated zone by data from DS
/ZonePrint — Display all records in the zone
/ZoneResetType — Change zone type
/ZoneResetSecondaries — Reset secondary\notify information for a zone
/ZoneResetScavengeServers — Reset scavenging servers for a zone
/ZoneResetMasters — Reset secondary zone's master servers
/ZoneExport — Export a zone to file
/ZoneChangeDirectoryPartition — Move a zone to another directory partition
/TrustAnchorsResetType — Change zone type for a trust anchor zone
/EnumRecords — Enumerate records at a name
/RecordAdd — Create a record in zone or RootHints
/RecordDelete — Delete a record from zone, RootHints, or cache
/NodeDelete — Delete all records at a name
/AgeAllRecords — Force aging on node(s) in zone
/TrustAnchorAdd — Create a new trust anchor zone on the DNS server
/TrustAnchorDelete — Delete a trust anchor zone from DNS server or DS
/EnumTrustAnchors — Enumerate records at a name
/EnumDirectoryPartitions — Enumerate directory partitions
/DirectoryPartitionInfo — Get info on a directory partition
/CreateDirectoryPartition — Create a directory partition
/DeleteDirectoryPartition — Delete a directory partition
/EnlistDirectoryPartition — Add DNS server to partition replication scope
/UnenlistDirectoryPartition — Remove DNS server from replication scope
/CreateBuiltinDirectoryPartitions — Create built-in partitions
/ExportSettings — Output settings to DnsSettings.txt in the DNS
server database directory
/OfflineSign — Offline signing zone files, including key genera-
tion/deletion
<Command Parameters>:
DnsCmd <CommandName> /? — For help info on specific Command
|
