Troubleshooting Name Resolution Issues

EXAM 70-293 OBJECTIVE 2.5.2

Proper name resolution is critical to the smooth operation of the network. When name resolution fails, for whatever reason, users might be inconvenienced, and connectivity to critical systems might be compromised. Usually, a name resolution failure requires immediate action on the part of the administrator, even if the failure is not widespread.

Often, problems that appear to be related to name resolution are, in fact, the result of problems that occur further down in the OSI or DoD networking models for TCP/IP. For example, if a router fails and the DNS or WINS servers are on the other side of the router from the client, clients will not be able to resolve names. The failure of a router occurs at Layer 3 (Network layer) of the ISO model.

As part of a prudent and successful troubleshooting strategy, it is important to troubleshoot from the bottom of the OSI model up, ensuring the following:

• The hardware is functioning properly.

• The computer is configured properly.

• The computer is able to communicate with hosts on the local subnet.

• The computer is able to communicate with the router configured as the default gateway.

• The computer can communicate with remote networks on the far side of the router.

Usually, this troubleshooting will rely on tools such as Ipconfig to verify configuration and PING (using IP addresses) to test communication.

Name resolution occurs further up in the OSI or DoD model. In a Windows environment that relies on both DNS and NetBIOS (which use the WinSock and NetBT interfaces, respectively), it is sometimes necessary to distinguish which interface used for name resolution is causing problems. You need to discover if is the failure specific to NetBIOS or DNS (host name resolution). To make this determination, you can test name resolution using applications that are specific to these interfaces. For example, to test NetBIOS name resolution, try to connect to shares using a UNC path or the net commands, invoked from the command line. As long as the name you are trying to resolve does not include dots or is less than 15 characters long, Windows clients will default to using NetBIOS resolution first. If name resolution is successful, but you encounter a delay, chances are that NetBIOS resolution failed but that the fallback host name resolution was successful. To test host name resolution, you can use WinSock applications, such as NSLookup, Telnet, FTP, HTTP, and so on.

You should also consider whether NetBT is enabled, either by means of a DHCP server option or as a configuration on the client computer. Some applications, such as Microsoft Exchange Server, still require that NetBT be enabled to work properly. In troubleshooting name resolution problems, you should therefore take into account the applications that may be involved and their dependence on either the WinSock or NetBT interfaces to work properly.

It is sometimes obvious that the problem is specific to either host name or NetBIOS name resolution. In any event, after you have made the determination, you can proceed to troubleshoot according to the interface (WinSock or NetBT) that is involved.

Troubleshooting Host Name Resolution

EXAM 70-293 OBJECTIVE 2.9

Assuming you have eliminated any antecedent causes that have to do with connectivity and communication on the network, troubleshooting host name resolution is easier if you can isolate whether the problem is caused by problems with client configuration or by problems with the DNS server. Problems with DNS clients include improperly entered addresses for the primary and secondary DNS server, in addition to improperly configured DNS suffix search list settings. Problems with DNS servers include improperly configured delegations; improperly configured restrictions on zone transfers; missing, incorrect, or stale resource records; and so on.

Effective troubleshooting of Microsoft DNS issues requires a familiarity with the process of DNS name resolution (for example, recursive versus iterative queries and authoritative versus nonauthoritative responses), dynamic updates, zone transfers, stub zones, forwarding, and so on.

A familiarity with DNS-related troubleshooting tools such as NSLookup, Ipconfig, Dnscmd, and DNSLint, will help to ensure that you can trace the source of the problem effectively. Using NSLookup, you can request either an authoritative or nonauthoritative response from the DNS server, which can help you to narrow down the problem further; for example, to determine whether a stale record is coming from the DNS cache or not. Furthermore, with NSLookup, you can use debug mode to provide a great amount of detail in the output of the command. You can use DNSLint to check all your delegations and verify the correct configuration of well-known services such as SMTP. Issues with dynamic registration can sometimes be resolved by using the command ipconfig /registerdns. Incorrect entries in the client DNS cache can be resolved with the ipconfig /displaydns and ipconfig /flushdns commands. Some tools that are not specific to DNS, such as Nltest, can help to troubleshoot DNS-related issues with domain controllers.

Issues Related to Client Computer Configuration

Many problems with DNS resolution have their origins in the client configuration, so verifying the correct client configuration is a good place to begin. To troubleshoot problems with client configuration, use the ipconfig /all command to verify the DNS configuration, and then use PING and NSLookup to verify communication with the DNS server. If you can ping the DNS servers but an NSLookup query against them fails, the issue is most likely related to a problem with the DNS servers. (This is the kind of situation where troubleshooting from the bottom to the top of the OSI model really pays off in helping to narrow down the problem.)

One of the more common and serious problems with client configuration is an improperly configured FQDN, which is set up in the properties of My Computer on Windows 2000 and Windows XP clients. If the FQDN is not present or is incorrectly configured on the client computer, name resolution can fail for domains that would otherwise be searched according to a domain suffix search list. For example, if the computer is a member of the corp.tacteam.net domain and the user enters and uses an unqualified name (for example, PServer1) in a DNS query for a host in the tacteam.net domain, the query will fail unless the FQDN of the computer is properly configured. (An unqualified name is one that doesn’t have a trailing dot.) By default, the DNS client uses a domain suffix search list based on the FQDN. So, if the host name cannot be resolved in the corp.tacteam.net domain, the suffix will be devolved to tacteam.net to find the host. To troubleshoot problems with domain suffix search lists, try to resolve the name at the client using the FQDN (that is, include the trailing dot). If this query succeeds but an unqualified query does not, the problem is related to the domain suffix search list.

Clients that have improperly configured FQDNs might also have problems with dynamic registration in the DNS zone. The client registration of a host record in a DNS requires that the primary suffix be properly configured. If the domain suffix is improperly configured, the client may be trying to register in a nonexistent or an unintended domain. To troubleshoot and resolve this problem, verify that the client computer is correctly configured with a primary domain suffix and that it can reach a name server that is authoritative for the domain name (you can simulate this by using NSLookup to perform an SOA RR query type for the authoritative zone). If the client receives its TCP/IP configuration from a DHCP server, verify that the DHCP server option for the domain suffix and other settings are configured correctly. Also, the client needs to be configured with the IP address of a DNS that contains the primary zone in order for the updates to occur. Meeting these conditions and then using the ipconfig /registerdns command to register the host in the domain might solve the problem. However, if the problem is still not resolved, chances are the source of the problem is the DNS server; for example, an ACL on the RR may be preventing the update. Using Event Viewer on the client computer can help you determine the nature of the problem.

If the DNS clients are getting incorrect responses to DNS queries, the problem might be related to their DNS cache. To clear the cache and force a new query to a DNS server for the host name, use the command ipconfig /flushdns. (Alternatively, you can use NSLookup to request an authoritative response.) If you have cleared the cache and are still getting incorrect responses to queries, it is likely the source of the problem has to do with the DNS server; for example, there might be an incorrect entry in the cache of the DNS server, a problem with zone transfers, or a delay in AD replication.

Issues Related to DNS Services

EXAM 70-293 OBJECTIVE 2.9.1

If you have determined that the problem you are experiencing is unrelated to DNS client settings or the client’s ability to communicate with the network, the problem is most likely related to DNS server configuration. To troubleshoot DNS server problems, you need to let the symptoms of the problem guide you to a likely cause and solution. Again, using a tool like NSLookup will help you get a clearer picture of the problem since it can provide more detailed information and be used to get either authoritative or nonauthoritative responses from DNS servers. The following is a brief list of guidelines to help troubleshoot problems with DNS servers:

• If clients cannot resolve names on the Internet or in domains for which their DNS servers are not authoritative using recursive queries, the problem might be related to the ability of the DNS server to perform recursion or to forward the query to a server that will perform recursion for it. In this case, check to make sure that the root hints file is present and the records are correct. If these settings are correct, your DNS server might be experiencing cache pollution. In this case, you should enable protection against cache pollution and restart the DNS service.

• If clients do not get correct records or are getting stale records, the cause could be the cache on the DNS client or DNS server. Examining and clearing the cache will eliminate the problem. However, if the problem is unrelated to cache, the cause could be failed or slow zone transfers to the secondary zones. If you are using Active Directory-integrated zones, the cause could be related to problems with AD replication. Comparing the RRs in the various zone files and looking at events in Event Viewer will help to confirm zone transfers as being the cause or the problem.

• If some clients cannot get responses to DNS queries from a multihomed DNS server but others can, the problem might be related to the listener settings on the DNS server. These settings can restrict which interfaces the DNS service will use to respond to queries.

• If you are implementing a round-robin configuration to provide load balancing and are not getting the desired results, check the settings for subnet prioritization. Round robin is a kind of load balancing that can be configured using multiple host records that have the same name but different IP addresses. When round robin is enabled, the DNS server will rotate responses among all the records. However, if subnet prioritization is also enabled, the DNS server will try to respond with a record that is on the same subnet as the DNS client.

• If zone transfers are failing between DNS servers, the cause could be improper restrictions on DNS servers that are authorized to pull zone information from the primary server. By default, the DNS server will allow zone transfers to only those DNS servers listed as name servers for the zone. However, you might need to reconfigure these restrictions so that you specify the IP addresses of computers that are authorized to pull zone information.

• Another cause of failed zone transfers is the use of nonstandard characters in DNS names. By default, Microsoft DNS servers are configured to load the zone even if they encounter bad data. However, BIND servers are not as forgiving. In addition, WINS forward and reverse lookup records can cause problems if replicated to BIND servers. You can prevent WINS records from replicating to BIND servers. If you are replicating to BIND servers, you should use only standard DNS characters.

• Another common cause of zone transfer problems is an incorrect version number in the SOA of the primary or secondary zone. To determine whether to request a zone transfer from the primary server, the secondary server will compare the version number of the primary’s SOA with its own. If the primary’s number is higher, the secondary will request either a full or an incremental zone transfer. If the version number is reset on the primary so that it is lower than the version number in the secondary’s SOA, the zone transfer will fail.

• If queries to subdomains are failing, the cause is most likely a lame delegation of authority. A lame delegation occurs when the name server and glue address records do not point correctly to the servers that are authoritative for the subdomain. NSLookup and DNSLint are useful tools in helping to troubleshoot problems with delegations.

• If dynamic updates are failing, the cause of the problem might be related to the security settings and ownership of RRs in their ACLs. For example, if a DHCP server is the original owner of a record and a client subsequently gets its IP address from another DHCP server, the dynamic update will fail. Another cause of failed dynamic updates is that the primary zone is, for whatever reason, unavailable. Dynamic updates can occur in only primary or Active Directory-integrated zones.

Troubleshooting NetBIOS Name Resolution

To avoid problems with NetBIOS name resolution in the first place, you should take very seriously the best practices that Microsoft recommends for the deployment of WINS servers and clients. In general, these best practices require the following:

• Be conservative in your estimates of the number of WINS servers you need.

• Use full replication partnership agreements.

• Use a hub-and-spoke replication topology to reduce convergence time in large environments.

• Do not install WINS on a multihomed server.

To troubleshoot problems with NetBIOS name resolution, you should first analyze the problem to determine whether it is a client configuration problem or a problem related to WINS server records or WINS server configuration, such as failed replication.

Issues Related to Client Computer Configuration

EXAM 70-293 OBJECTIVE 2.99

First, you should determine whether a problem that appears to be related to client configuration affects a single computer or a group of computers that all get their TCP/IP configuration from the same DHCP server or the same DHCP server scope. You should also verify the WINS server configuration by using the ipconfig /all command. The output of this command will list any WINS servers that are either manually configured or dynamically configured through DHCP. You should ping the IP addresses of the WINS servers listed in the client configuration to verify that communication is possible with these computers.

Another command you can use to troubleshoot problems related to client configuration is the nbtstat command. With the nbtstat command, you can cause a release and refresh of the NetBIOS registration for the client computer, view the remote name cache, view statistics on recent NetBIOS name resolution activity, and so on. Sometimes, a recently cached but incorrect entry in the remote name cache is causing a specific problem. You can also use the nbtstat command to clear the contents of the cache, except for those entries that are preloaded with the #PRE tag in an LMHOSTS file (these entries are obvious when you view the remote name cache using the nbtstat command).

In addition to verifying the correct configuration of the WINS server entries, you might want to consider whether the client is configured as an h-node, an m-node, a b-node, or a p-node client. For example, if the client is configured as an m-node client, it will use name query broadcasts before reverting to unicast name queries to the WINS server. If there is a duplicate NetBIOS name on the subnet, resolution to this name will occur first in the case of an m-node client.

Furthermore, you should consider the presence of an LMHOSTS file on the client computer and the order in which LMHOSTS will be used in name resolution queries. If the clients are using an LMHOSTS file and it appears that an LMHOSTS file is involved in the problem, you need to verify that the entries in the file are correct.

Issues Related to WINS Servers

In troubleshooting problems with name resolution that involve the WINS server, it is useful to first determine the scope of the problem. For example, does the problem involve dynamic or static name mappings, deleted records, replication, or a corrupted database? You should also consider any error messages that the NetBIOS client receives, such as “Network path not found” or “Duplicate name.” In addition, you should look at any events that are recorded in the System event log for the WINS service that might provide an indication of a corrupted database or problems with replication. Finally, you should confirm whether the problem affects one or multiple WINS servers. If the problem affects only one WINS server, you should first verify that the WINS service has started properly and that the database is not corrupted.

Problems Related to Static Mappings

You should avoid the use of static mappings except in situations where you need WINS to provide resolution to NetBIOS applications running on non-WINS clients or you want to provide static, permanent name mappings to mission-critical servers to mitigate the risk of redirection attacks. However, if you are using static mappings and the problem is related to these entries, you should do the following:

• Verify that the entries are correct and that they have replicated properly.

• If you have deleted the static mapping, you need to verify that the tombstoned record, in the case of a tombstone rather than simple deletion, has replicated properly.

• If the client error message refers to a “duplicate name” and there is a static mapping for the name, you need to ensure that the migrate on setting is enabled to allow the dynamic name registration to overwrite the manual registration.

Problems Related to Multihomed WINS Servers

Multihomed WINS servers are so often the cause of WINS-related problems that they deserve a special troubleshooting category. In general, you should avoid installing WINS on a multihomed server. Some of the problems you might experience with multihomed WINS servers can be hard to track down. If you are experiencing intermittent problems with name resolution or if you are having problems with replication, chances are that these can be traced to the configuration of the multihomed WINS server.

However, if you must use a multihomed WINS server and if you are experiencing problems, you should do the following:

• Verify that all network devices on the multihomed WINS servers are configured as routable interfaces with correct TCP/IP information. (You should never colocate the WINS service with the RAS service—that is just asking for trouble.)

• Verify that all TCP/IP configurations use the IP address of the WINS server for both their primary and alternate WINS servers. (You can leave this configuration blank if you like, because the WINS server will register itself without this configuration.)

• Verify that all the replication partners of the multihomed WINS servers are configured to replicate with all the configured IP addresses of the WINS server, and not the NetBIOS name.

Problems Related to Replication

Problems related to replication almost always are the result of not following Microsoft’s recommended practices, such as installing too many WINS servers, installing WINS on a multihomed computer, or using limited replication partnerships. For example, installing too many WINS servers (more than 20, according to Microsoft) can cause intermittent and hard-to-locate problems with replication.

In troubleshooting replication problems, you should first consider whether the problem is related to network communication and name resolution to the replication partners themselves. Consider the following questions:

• Can you ping the IP address of the replication partner?

• If the replication partner is a multihomed computer, have you configured the replication partner settings with the IP addresses of the multihomed computer, rather than the NetBIOS name?

• Does the NetBIOS name of the WINS server resolve to the correct IP address?

If you are using limited replication partnerships (push-only and pull-only) replication partners, you should ensure that these partnerships are set up correctly. Also, you might achieve best results by setting up reciprocal partnerships on the push and pull partners. For example, a computer that is configured as a pull-only partner to another WINS server should also configure that WINS server as its push partner. To illustrate, WINS-A has configured WINS-B as its pull partner; WINS-B in turn should configure WINS-A as its push partner. (To ensure that records are never pushed and replicated strictly according to the pull replication schedule, you can set the push trigger threshold to a very high number that will never be reached between pull replication cycles.)

If replication partnerships are configured correctly and there is good connectivity, but you are still experiencing intermittent problems, the version IDs on some replicated records may not be correctly incremented. You can resolve this problem by entering a new starting version ID for the WINS database in the WINS console or using the netsh command.