Irksome Nslookup Oddities

Undesirable behavior in the Win2K Pro version of an NT 4.0 friend

One of my favorite Windows NT 4.0 utilities is Nslookup. I've used this utility for years to troubleshoot a variety of DNS name-resolution problems. However, shortly after my company began upgrading its network workstations to Windows 2000 Professional, I started noticing strange behavior from Win2K Pro's Nslookup. DNS record lookup queries were failing, and Nslookup was using my secondary DNS server rather than my primary one. Before I go into detail about the Win2K Pro Nslookup quirks that have been bugging me, let's recall the good ol' days of the reliable and useful NT 4.0 Nslookup utility.

The DNS Swiss Army Knife
Nslookup lets you directly query DNS servers for information such as the IP address name assigned to a particular host and whether particular record types within a DNS zone file are present and operating properly. This information is useful for troubleshooting as well as setting up new DNS zone file data.

To perform a simple-name (i.e., name—to—IP address) or reverse-name (i.e., IP address—to—name) lookup, at a command prompt, you simply type the Nslookup command followed by a host's name or IP address. The utility returns the corresponding IP address or host name. Within domain files on DNS servers, Address (A) records assign name—to—IP address mappings. When you use Nslookup commands, you're querying the contents of these A records.

You can also use Nslookup to query DNS servers for other record-type data, such as Name Server (NS) records, which identify the DNS servers supporting a particular domain name; Canonical Name (CNAME) records, which define aliases for DNS hosts assigned through A records; and mail exchanger (MX) records, which identify which mail hosts handle mail for a particular domain. You can query for all record types or a particular record type.

Internet mail servers use DNS queries to discover MX record information such as the server address and record preference value. When troubleshooting problems such as message bounces or delivery to the wrong mail server, manually performing the DNS queries can provide useful information. Doing so lets you see what DNS information remote servers are seeing, which can provide clues about your problem's source. You can use Nslookup to manually perform DNS zone-file queries against the DNS server of your choice.

Another useful Nslookup function is to display all the mail servers for a particular domain. To do so, set Nslookup to query only for the MX record type and provide the domain name of the domain that you want information about. The following commands start an Nslookup session and query for the xcedia.com domain. First, at a command prompt, type

nslookup

Press Enter, then type

set type=mxxcedia.com

This query produces the output that Figure 1 shows.

Quirk #1: Failed Record Queries
The first frustrating behavior I observed from Win2K Pro's Nslookup utility was occasional failures when I issued DNS record- lookup queries. On some machines, MX record queries produced results similar to those obtained under NT 4.0. MX record queries on other machines, however, produced no MX record data, instead providing general zone-file information such as the primary name server, zone-file serial number, and Time to Live (TTL) setting. When I performed the previously mentioned query on a Win2K Pro system in my network, the output included no MX record data, as Figure 2 shows.

After a Windows 2000 Magazine reader wrote me to complain about similar problems with Win2K Pro's Nslookup utility, I decided to investigate what Microsoft had changed in the new version and why I was receiving different NSlookup results on different machines. I began my investigation by attempting the same Nslookup MX record query on different Win2K machines. In my test, the MX record query failed on every Win2K machine. However, when I logged on to an NT 4.0 system in the network, the same query worked just fine.

After further experimentation, I was able to make the MX record query work on the Win2K machines. To do so, I had to use the server server_name command at the Nslookup prompt to manually change the systems' default DNS server. (In this command, server_name is the DNS host name or IP address of the DNS server you want Nslookup to query.) By default, Nslookup sets a system's DNS server to the first server configured in the client's IP stack. After I changed the server to an alternative server, I was able to successfully issue an MX record query from the Win2K systems.

I started thinking that this behavior was evidence of a weird initialization bug in Nslookup when I realized that in changing the DNS server setting, I had inadvertently changed the type of DNS server that the clients were connecting to. When I reexamined the Win2K Pro Nslookup sessions, I discovered that each session had connected to an NT 4.0 DNS server on my network. When I changed the server setting, I had specified a Win2K DNS server. Could a glitch between Win2K Pro's Nslookup client and NT 4.0's DNS server be the root of my problem?

Experimentation confirmed that this was the case. I determined that only NT 4.0 DNS servers are a problem for Win2K Pro's Nslookup; Win2K Pro's Nslookup worked just fine when talking to other DNS servers, such as Win2K DNS or BIND.

Several potential workarounds exist for this problem. You can simply use the server server_name command to change the DNS server to a non—NT 4.0 DNS server. Alternatively, you can configure your Win2K client's IP stack to list a non—NT 4.0 DNS server first. Another solution is to copy the NT 4.0 version of Nslookup from an NT system to your Win2K Pro system. I tested this solution, and it worked. Upgrading to Win2K Service Pack 2 (SP2) also solves this problem.

Quirk #2: Strange Server Selection
The default DNS server selection is another notable quirk of Win2K Pro's Nslookup command. Under NT 4.0, Nslookup sometimes issues the following cryptic error message upon initialization:

DNS request timed outTimeout was x secondsCan't find server name for address : Timed outDefault servers are not availableDefault Server: UnKnownAddress: 

where xxx.xxx.xxx.xxx is the IP address of the first DNS server configured on the client on which Nslookup is running. Under NT 4.0, this strange error message doesn't seem to affect the program's functionality. Despite this error message, Nslookup queries run.

In the Microsoft article "'DNS Request Timed Out' Error Message When You Start Nslookup from a Command Line" (http://support.microsoft.com/support/kb/articles/q242/9/06.asp), Microsoft explains that this condition occurs because upon initialization, Nslookup attempts to perform a reverse lookup of the first DNS server's IP address. If it can't perform this reverse lookup (e.g., because no Pointer—PTR—reverse-lookup record exists), Nslookup issues the aforementioned error.

Under NT 4.0, Nslookup issues the error message, but for subsequent queries, uses the first-listed DNS server even if no reverse-address lookup is possible. Under Win2K Pro, Nslookup issues the error message upon initialization. When you issue a query, Nslookup skips the first DNS server on the client's list and continues through the list until it discovers a server for which it can complete a reverse lookup (the Microsoft article fails to mention this server search). In my situation, this quirk caused my Win2K Pro Nslookup sessions to use my secondary NT 4.0 DNS server rather than my primary Win2K server and thus caused my query to fail (due to the behavior explained in Quirk #1).

I get frustrated when Microsoft reduces the functionality of important utilities in the course of an upgrade. Upgrades are supposed to result in better versions of OS utilities. Unfortunately, in cases such as Win2K Pro's Nslookup utility, upgrade doesn't always mean progress.