Irksome Nslookup Oddities

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 out
Timeout was x seconds
Can't find server name for address : Timed out
Default servers are not available
Default Server: UnKnown
Address: 

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.