DNS Name-Resolution Troubleshooting
DNS
is the backbone of any modern network, and Windows networks are no
exception. Windows clients utilize DNS resolution for the following
services now:
Active Directory (AD) domain logon and other AD service lookups
File and print sharing (a DNS lookup is used by default initially)
Access of Microsoft Exchange server services
These are just a few of
the services for which a Windows Vista client either requires or
utilizes primarily DNS name resolution services when accessing.
Windows Vista clients
should all be assigned two DNS server addresses either through DHCP or
static configuration. This helps ensure stability of name resolution in
the event of a single server being incapacitated or unreachable.
You can discover which DNS
server addresses have been assigned to a Windows Vista client by using
the option to view status of a connection in the Network and Sharing
Center and then selecting the details of that connection. An example was
displayed previously in Figure 4.9. Going to the command line and entering ipconfig.exe /all produces the same information.
If an issue is
discovered within configuration information displayed in the connection
details, you can easily attempt a repair by clicking the Diagnose
button on the General tab of the Network connection properties. This
prompts the use of the Network Diagnostics Framework built into Windows
Vista. A solution is given at the end of the diagnosis.
A common problem encountered
is when application services located on one server are moved or
reinstalled on another server. Alternatively, the current server where
the application service is located has its IP address configuration
modified to accommodate a change in the network topology. When either
issue occurs, name resolution problems result as network clients attempt
to access that service on the original IP address. One or more issues
need to be resolved: An old DNS entry has not been updated on the DNS
server, the local DNS cache of the Windows Vista computer, or the DNS
cache on the name server that originally resolved the request.
Initially,
you need to ensure you have reconfigured the DNS Address (A) record on
the DNS server housing the DNS zone with the new IP address of the
server where the application now exists. To correct the latter caching
issues, you need to focus on which is at fault. If the fault is a
caching problem on a DNS server that either forwarded the query or
performed a recursive lookup, flush the record from the cache on the DNS
server. If you suspect the caching issue is local to the DNS client,
flush the local DNS cache by going to a command line on the problematic
Windows Vista client and typing ipconfig /flushdns.
This removes all current DNS cache entries. The Windows Vista resolver
service on the local computer is forced to perform a new lookup off one
of its configured DNS server addresses. The issue, if local, is easy to
determine if other Windows Vista clients on the local network can
appropriately access the remote server by name.
To view the local DNS cache on a problematic client, type ipconfig /displaydns
at the command line. Review the resolved DNS entries within the cache
to ensure that the IP address of the server where the application
service resides is listed correctly.
Troubleshooting NetBIOS Name Resolution
There are still a handful of
times when NetBIOS name resolution is required prior to accessing some
legacy service. For instance, NetBIOS name resolution is still needed in
some of the legacy Microsoft Exchange application services, in an
existing client/server application, or possibly when accessing file and
print services that are still using conventional NetBIOS resolution. In
any case, there are a few steps that you can take on the Windows Vista
client to ensure that the client is configured appropriately or has not
held onto a cached entry past its usefulness.
Using the display in Figure 4.9, you can see that a single WINS server has been configured for use by a Windows Vista client. By typing the command ipconfig /all, you are also able to view the WINS server entry.
For instance, if you want to map a drive to a file share on a remote server, you may use the tried-and-tested net use command from a command prompt. If you use only the NetBIOS name of the server in the mapping like
net use m: \\main\fileshare
a Windows Vista client attempts to use NetBIOS name resolution services first.
Caution
Be Wary of Name Resolution Services Questions on the Exam
I have had some concern with the way questions dealing with name
resolution services or command-line utilities for troubleshooting name
resolution issues have been handled on past Microsoft exams. There are
far more variables that affect whether a NetBIOS service or DNS service
resolves a name first than what the preceding net use mapping scenario may lead you to believe.
Microsoft has quite
an extensive set of flowcharts inside the resource kits from previous
Windows server products that are quite dizzying to read and follow.
Therefore, you should follow some basic tenets when answering these
questions:
If the name that is to be resolved is an FQDN, assume DNS regardless whether the application appears to be NetBIOS-based.
If
the name that is to be resolved is a simple hostname, but you know the
application is Winsock based, assume DNS is used initially.
If
the name to be resolved is a simple hostname with fewer than 16
characters, and the application is NetBIOS based (like the preceding net use drive mapping), assume that NetBIOS is probably used first.
Finally,
if the question is extremely vague as to what type of application it
is—in other words, no reference is given to its origin or what clients
are accessing it (for example, Windows 9x clients) and all you are given
is some generic hostname like “Server1”—go with DNS troubleshooting
techniques if given the choice between DNS or NetBIOS utilities.
Even these few tenets have issues, but they are the best way to go when these questions appear vague on the exam.
When you are troubleshooting NetBIOS issues on a local computer, Nbtstat is the primary NetBIOS name resolution utility. Table 1
shows the different switches you should be concerned with when using
Nbtstat to help resolve NetBIOS name resolution problems on a Windows
Vista computer.
Table 1. Nbtstat.exe Options Defined
| Option Name | Option Description |
|---|
| Nbtstat.exe –c | Lists NetBIOS names cached on a local machine and their IP addresses |
| Nbtstat.exe –n | Lists local NetBIOS names in use by the local computer |
| Nbtstat.exe –r | Lists number of names resolved by broadcast or by WINS |
| Nbtstat.exe –R | Purges and then reloads the NetBIOS name cache |
| Nbtstat.exe –RR | Sends a name release to the remote WINS server and then does a refresh of those registered names |
Troubleshooting Connections with Netstat.exe
Another useful utility that Microsoft has constantly improved over the years is Netstat.exe. This utility’s primary function is to diagnose TCP/IP network connections. Other useful purposes for Netstat.exe are displaying protocol statistics for IP, UDP, and TCP and displaying the routing table. Table 2 shows the options that are important to the use of Netstat.exe.
Table 2. Netstat.exe Options Defined
| Netstat.exe Option | Option Description |
|---|
| -a | Displays all connections and listening ports |
| -n | Displays addresses and port numbers of a defined connection |
| -o | Displays the owning process ID associated with each connection |
| -p | Shows connections for the protocol specified by protocol; IP, IPv6, UDP, TCP, and so forth |
| -r | Displays the routing table |
| -s | Displays per protocol statistics |
Several of the options can be used together to align connections with protocols, ports, and IP addresses in use. Figure 5 shows a Netstat.exe display with –a, -o, and –n options.
Figure 5
shows that this Windows Vista computer is listening on several ports.
For example, this computer has an active Server Message Block (SMB)
connection with a computer at IP address 10.1.0.4 using local TCP ports
49450, 49451, 49452, 49454, and 49455. If you were looking at this
display, you could also tell that this Windows Vista computer does not
have the Remote Desktop Protocol (RDP) enabled for an incoming
connection request. After RDP is enabled for incoming requests in the
Advanced System properties, Figure 6 shows that an RDP listening port has been enabled.
You can see part of the way
down the figure that TCP port 3389 for RDP is now set to listen for
incoming requests. You can cross-reference this connection with its
corresponding Process ID to discover which Windows Vista service is in
control of this process. From the display, you see that Process ID 1428
is the index value the Windows Vista computer is using to track this
process. Using the Task Manager application, you are able to see that
the system account Network Service owns this process. Figure 7 has this process selected.
Tip
Windows Task Manager is a fine
tool for initial inspection of applications, the resources that they
use, the Process ID of the application, the system or user account in
use of the process, and several other pieces of valuable information
regarding resources of any particular process. A more useful utility
would be the Process Explorer tool from Sysinternals. Sysinternals was
acquired by Microsoft, but the Microsoft download site still refers to
the utility as the Sysinternals Process Explorer utility. It has far
more granular information on each process running in your computer. The
Process Explorer utility is a good initial starting point for
investigating mysterious executables running on your computer.
Troubleshooting with the Older Utilities
Several older utilities deserve mentioning for troubleshooting network connectivity.
PING
The PING utility tests
end-to-end connectivity by sending ICMP “echo request” packets to a
target computer. If the connection to the end target is successful, the
target computer—or network device such as a router, network print
server, or network management interface—replies with an ICMP “echo
response.”
Tracert
The Tracert utility details
the path taken from a source to a target computer along with the time
difference between the original source each hop along the path to the
target.
PathPING
The PathPING utility was
introduced in Windows NT 4.0 and combines the functionality of Tracert
and PING. PathPING provides the path details similar to Tracert while
also providing the end-to-end connectivity between a source and target
computer like PING.
Troubleshooting Routing
The
necessity for assigning a default gateway address in an environment
where the network topology involves routing was discussed previously. To
ensure that you have a router that is successfully understood by the
local computer, you can check its routing table. Figure 8 shows the routing table of a Windows Vista host using the route command with the print option from the command line.
Figure 4.15
shows there is a only one route that will allow this computer to
connect to any other computer or network device on a remote network.
That is the first route listed in the route table. Following is a
snippet from the route table:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.1.0.100 10.1.0.132 25
The Network Destination
column is the column that signifies the remote network for a particular
connection, and the Netmask column denotes the Prefix length of the
network route. If a remote network destination is not listed in the
route table, the route entry with the value 0.0.0.0 and a Netmask value
of 0.0.0.0, which refers to any network with any mask, is used. This
entry therefore matches any other route not specifically found in the
route table. It is also the worst route to any other destination. If any
other route entry in the route table had any portion of contiguous bits
starting from the high order bits matching the desired network
destination, that route would have been chosen instead. Because computer
desktops do not usually contain any other route information regarding
remote networks in their route table, the default route tends to be the
best route, as well as the only route to choose for remote network
connectivity.
