Navigating Name Resolution, Part 1

If you asked me, as a network consultant, to choose the most problematic area of Microsoft Windows networking, my unblinking answer would be name resolution. You can directly relate ailments such as sluggish performance, client computers' or applications' inability to connect to servers, incomplete browse lists, and obscure error messages to problems resolving computers' names to their IP addresses. To help you overcome these maladies, I offer a name-resolution primer, discuss some of the lesser-known causes behind name-resolution problems, and resolve a common name-resolution misunderstanding.

An Equal Opportunity Annoyer
In the Internet's DNS-driven namespace, name resolution is fairly straightforward. To resolve names, clients query DNS servers, which either provide the IP address of the host in question or inform the client that no such name exists—a generally transparent process. Not so with Windows-based networks' name-resolution process, which involves additional layers and services, including WINS servers and clients, broadcasting, and static name-to-IP address mapping files (i.e., HOSTS and LMHOSTS files). These additional name-resolution methods complicate the process and make diagnosing and resolving problems trickier. Before I jump into the complicated mechanics, I want to cover the fundamentals of name resolution in a TCP/IP environment.

Resolution Rudiments
Unlike protocols that rely exclusively on broadcasting (e.g., IPX/SPX, NetBEUI) to resolve names, TCP/IP in a Windows environment can also use point-to-point name server queries. Point-to-point queries are preferable because they're more reliable, can easily cross routers, and use less network bandwidth than broadcast queries. (A point-to-point query is like a friend calling you on the telephone to ask a question, whereas broadcasting is like a friend standing in front of your house yelling into a megaphone to ask a question. In the former case, the communication involves only your friend and you; in the latter case, all your neighbors become involved.)

The Four Node Types
Clients of all Windows OSs—except Windows 2000 (Win2K)—require the presence of the NetBIOS session layer with a network transport protocol. (Win2K doesn't rely exclusively on NetBIOS to support networking activities: Win2K's TCP/IP implementation can use DNS to locate network servers and services.) So, the OSs' TCP/IP protocol stacks support a modified form of TCP/IP called NetBIOS over TCP/IP (NetBT). Windows clients that use NetBT (i.e., WINS clients) can attempt name resolution by using one of four NetBT node types: b-node, p-node, m-node, and h-node.

B-node. B-node clients use broadcasts to register their names and resolve the names of other machines on the network. B-node is undesirable for most networks because IP routers typically can't forward broadcasts, so b-node limits a client's scope of resolution to one IP subnet (i.e., network segment). And because b-node relies on network-saturating broadcasts, it uses more bandwidth than point-to-point methods. B-node is the default for Windows clients that don't have a configured NetBIOS Name Server (NBNS—the generic name for a WINS server, which is typically a Win2K- or Windows NT-based server). NT also supports a slightly altered form of b-node called modified b-node. A modified-b-node client first checks its local name cache for a name-to-address mapping. If the client doesn't find the address in memory, it resorts to broadcasting. If neither of those methods works, the client checks the local LMHOSTS file (if it exists) in the \%systemroot%\system32\drivers\etc folder on Win2K or NT systems or in the Windows folder on Windows 9x systems.

P-node. P-node clients register their names with a WINS server and use that server to resolve names. P-node has a major drawback: If the server can't resolve a name or if you've configured the client with incorrect name-server addresses, the client can't log on to the network because it can't discover the name of a domain controller to process the logon request.

M-node. M-node resolution is one of two hybrid node types. When attempting to resolve names, m-node clients use b-node-style broadcasts then point-to-point WINS server (i.e., p-node) queries, in that order. M-node is optimal for WAN subnets that have no local name server and connect to the WAN by low-bandwidth links. In these cases, using broadcasts to resolve names helps minimize traffic on the WAN links.

H-node. H-node resolution is the default for Windows clients that you've configured (either manually or with information from a DHCP server) to register with one or more WINS servers. H-node is essentially the opposite of m-node: Clients register their names directly with WINS servers and use these servers first when attempting to resolve names. If the name server queries fail, the client then uses b-node-style broadcasts.

How do you determine a WINS client's node type? By default, a client uses b-node unless you configure it to register with at least one WINS server, in which case the client will use h-node. However, you can override this behavior. For example, you can use a DHCP scope option (i.e., a configuration parameter that passes to a DHCP client) to configure clients to use a specific node type. (You can also use a Registry entry to manually configure the WINS node type setting on most Windows versions. However, I don't recommend this method because the manual Registry configuration overrides even a dynamic DHCP-assigned node type, making this method less flexible.)

Because a majority of NT networks use WINS servers, a majority of Windows-based LAN clients on these networks use h-node resolution. If neither point-to-point nor broadcasting is successful, h-node WINS clients then use other methods. H-node uses the following progression to attempt name resolution:

1. Check whether the queried name belongs to the local machine.
2. Check the local name cache, which by default retains resolved names for 10 minutes.
3. Direct a point-to-point query to the configured WINS server or servers.
4. Use a broadcast query.
5. Use a local LMHOSTS file, if one exists.
6. Use a local HOSTS file, if one exists. (A HOSTS file resides in the \%systemroot%\system32\drivers\etc folder on Win2K or NT systems or in the Windows folder on Win9x systems.)
7. Issue a point-to-point query to any configured DNS server or servers. In NT, h-node WINS clients will attempt this step only when you select the Use DNS for Windows name resolution check box in the TCP/IP Configuration dialog box. This setting maps to the EnableDNS Registry subkey of type REG_DWORD under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters subkey in NT or the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VXD\MSTCP subkey in Win9x. Despite its name, the EnableDNS subkey controls only whether a client uses DNS servers during NetBT name resolution and doesn't affect the use of DNS for other purposes (e.g., resolving Web site names in a browser). By default, NT disables the setting (i.e., sets the value to 0), whereas Win9x enables the setting (i.e., sets the value to 1).

Now you understand some of the basics. But you still need to examine why name resolution can cause networking problems.

DNS Where You Least Expect It
DNS plays a much larger role in name resolution than the previous method order implies. H-node WINS clients query DNS servers only after all other name-resolution attempts have failed and only if you've enabled the client to use DNS for Windows name resolution. However, h-node WINS clients attempt to use a DNS server as if it were a WINS server: The client uses a WINS-style NetBIOS name query, rather than a DNS-client name query, to send a name-resolution request to the DNS server. As a result, unless your DNS server happens to be your WINS server and has a registration in its database for the queried name, this h-node attempt is likely to fail.