Navigating Name Resolution, Part 2

Conquer hidden name-resolution problems

Even the savviest Windows NT administrators don't fully understand Windows networks' name-resolution process. And who can blame them? In a Windows world riddled with multiple name-server standards, changeable client-resolution orders, self-destructive WINS servers, name-resolution-modifying service packs and patches, and a bevy of contradictory Microsoft articles, I can't imagine anyone avoiding problems. Your only hope is to understand Windows name-resolution methodology so that you can troubleshoot problems when they arise on your network. (In "Navigating Name Resolution, Part 1," June 2000, I explained the basics of name resolution, described hidden causes and common misunderstandings that relate to name resolution, and offered a few workarounds for specific situations.) I've researched a few solutions that you can employ to ease your name-resolution woes.

Good HOSTS
One solution that Microsoft recommends liberally in its articles is to use the client computer's HOSTS file, if one exists. A client always checks the HOSTS file before it checks DNS (i.e., HOSTS-file name resolution is second only to checking the client's local name cache). Therefore, you can avoid DNS-server-query timeouts if the HOSTS file contains the queried names. However, I don't like this solution because it requires you to manually deploy and update static text files on multiple remote machines as you add new machines to the network or change server names or addresses. The lone benefit of the HOSTS solution is that it provides the fastest possible name resolution. If speed is your top priority and you don't mind maintaining individual HOSTS files on multiple clients, this solution might be for you.

Use WINS
Another solution is available for NT shops that run DNS servers. As I explained in part 1, name-resolution delays can occur when a client can't connect to the DNS server (or servers) that acts as the client's primary connection. However, if that server is an NT DNS server that is accessible from both the internal network and the Internet, you can configure the server for all LAN and remote clients, go to DNS Manager, open a zone's Properties sheet, go to the WINS Lookup tab, and select the server's Use WINS Resolution option, which Figure 1 shows. When you take these steps, both internal and external users can talk to the server for name resolution, and the DNS server can respond to a client's dynamic-name query by querying WINS for the name. The Use WINS Resolution option integrates DNS with WINS and permits a dynamic form of DNS under NT 4.0. (This DNS configuration leverages WINS to provide dynamic capabilities but isn't the same as the dynamic DNS—DDNS—protocol that Windows 2000 supports.)

This option might not be feasible for everyone. To take advantage of this solution, you must have an internal DNS server that is also accessible from the Internet, an IP addressing and firewall scheme that lets clients talk to the DNS server's IP address from within and from outside the LAN, and a willingness to maintain a DNS server or servers. Also, you might understandably have security concerns about a DNS server that is accessible to both the internal LAN and the Internet and about the possibility of obtaining information about internal IP hosts through the DNS server. You might be able to work around the second prerequisite (i.e., letting both internal and external clients access your DNS server's IP address) by entering two DNS server addresses on the client: one for the DNS server's external IP and one for its internal address. Thus, the worst-case scenario is that the client can't reach the first DNS server (e.g., when connected to the internal LAN through a RAS connection), so it moves on to the second address, which succeeds. In addition, you can mitigate the third prerequisite (i.e., maintaining a DNS server) by configuring the DNS server as a forwarder so that it simply passes queries on to Internet DNS servers such as those that your ISP maintains.

New Order
Another potential solution is to change the name-resolution order on a client. You can configure a client to use NetBIOS over TCP/IP (NetBT) name-resolution methods and query WINS before it queries DNS. This way, you might avoid problems that stem from the client's default name-resolution behavior. (For information about clients' name-resolution behavior, see "Navigating Name Resolution Part 1.")

When I began to investigate this idea, I was encouraged to find several Microsoft articles that explained how to change the name-resolution order on clients running several Windows platforms. "How to Change Name Resolution Order on Windows 95 and Windows NT" (http://support.microsoft.com/support/kb/articles/q139/2/70.asp) describes two methods—one for NT and one for Windows 95—that let you manually control the order in which Windows attempts name resolutions. (For a list of name-resolution-related Microsoft articles, see "Name-Resolution Resources.") I tried the Win95 method first. In Win95, you control name-resolution order through a group of four Registry subkeys: LocalPriority, HostsPriority, DnsPriority, and NetbtPriority. (These subkeys are of type REG_DWORD and reside under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesVXDMSTCPServiceProvider key.) The four subkeys control the relative priority of using the local name cache, the HOSTS file, DNS, and NetBT name-resolution methods (including WINS), respectively. The values can range from -32768 to 32767 (lower numbers specify a higher priority) with the following default values (in decimal):

These values explain the client's preference for DNS (i.e., DnsPriority = 2000) over WINS (i.e., NetbtPriority = 2001). As you might expect, the article suggests that you simply reorder the values so that DNS has a higher value (and thus a lower priority) than NetBT and WINS. This suggestion seemed straightforward, so I implemented the changes on my Win95 OEM Service Release 2 (OSR2) test system and rebooted. To my dismay, I detected no difference in the client's name-resolution order: My network monitor showed that the client was still querying DNS first. Another Microsoft Web site search yielded a different article, "Windows 95 ServiceProvider Priority Values Not Applied" (http://support.microsoft.com/support/kb/articles/q170/6/19.asp). It essentially says, "Whoops, sorry, we messed up in the first article." Apparently, the previous article's suggested changes don't work because earlier Winsock versions (i.e., versions earlier than wsock32.dll 4.00.1112) contain a bug that causes the system to read the Registry data from the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSTCPServiceProvider Registry key. The article suggests that to correct the problem, you can manually mirror the values at the original, correct location to the incorrectly queried location. But I was shocked to discover that after I made these changes, my Win95 OSR2 client still queried DNS first. Even after I upgraded the client to Win98, I couldn't make any difference in my client's name-resolution order.

Just when I had all but given up on these Registry values, I installed Win98 Second Edition (Win98SE), and my client suddenly began querying WINS before DNS. Puzzled over these inconsistencies, I returned to the Microsoft Web site. I found some articles that implied that the Registry values only work with Winsock 1.x and some articles that implied otherwise. I tried everything I could think of, but I never successfully reversed the order on Win95 OSR2 with Winsock 2.x. I might have been more successful using the Win95 retail version, and I don't know whether these problems were the result of buggy code, inaccurate Microsoft documentation, or a combination of the two. However, the experience left a bitter taste in my mouth about the reliability of some Microsoft articles.

Fresh from my Win95 defeat, I decided to tackle the recommended solution for NT clients. I had a much more pleasant experience than with Win95. The NT modification takes the form of a Registry DnsNbtLookupOrder subkey (naming is case sensitive) of type REG_DWORD. This subkey doesn't exist by default, so you must create it in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Registry key. The subkey can have a value of 0 or 1. The default value (i.e., 0) instructs the client to use DNS before it uses NetBT methods; a value of 1 instructs the client to first use NetBT methods. As Figure 2, page 93, shows, I added the subkey and set its value to 1, and the client system began querying WINS before DNS.

What's the downside to using this method to change a client's name-resolution order? Potentially, this solution can introduce a minor (i.e., several-second) delay when clients query names than aren't on the local LAN or that aren't resolvable using WINS. For example, I noticed that browsing to an Internet-based Web site on my newly modified client took a few seconds longer that it had taken previously (although the WINS timeouts were much faster than the DNS timeouts I'd experienced earlier). Whether this trade-off is acceptable will probably depend on how much time the user in question spends on browsing the Web and engaging in other Internet-related activities vs. how much time the user spends connected to the company network resolving internal server names. Because most users spend a significant amount of time accessing the Internet, the best solution in most cases will probably be to upgrade to NT Service Pack 4 (SP4) or later (or to Win98SE on Win9x systems). Another alternative is to upgrade to Win2K Professional, which also has quick DNS server timeouts.

In addition, not all name queries are created equal. A Windows client or application can generate two kinds of name queries: NetBIOS name queries and host name queries. Applications that send NetBIOS name queries bypass DNS and use the NetBT methods (which usually begin with WINS). Other applications and utilities make generic name queries, which the client handles as host name queries and hands off first to DNS. (You might be surprised to discover that even Microsoft Outlook uses generic host name queries to resolve the name of its Exchange servers. Because Outlook's server field can accept Internet Fully Qualified Domain Names—FQDNs—the application isn't limited to using only NetBIOS names.) Thus, these applications will suffer when DNS-timeout-related problems occur on a client PC. Most non-NetBIOS-centric commands and utilities, such as the Ping utility, issue host name queries as well. However, some applications and utilities bypass DNS and pass queries directly to NetBT. For example, when you type the Uniform Naming Convention (UNC) phrase

\SERVER1

in the Start, Run dialog box to bring up a list of shared resources on a server named SERVER1, an h-node client will process the request as a NetBIOS name query, as Figure 3 shows. Other UNC-style name references, such as those you use in drive mapping for logon scripts, also exhibit this behavior. However, on my network, I noticed more generated host name queries than NetBIOS name queries.

Knowledge Is Power
Armed with an understanding of Windows clients' name-resolution behaviors on IP networks and with the techniques I've discussed for changing these behaviors, you're in a better position to control and optimize your network's performance. Now that you're aware of these lesser-known behaviors, you can use that knowledge to navigate the sometimes-troubled waters of name resolution.