Now that we’ve summarized the various name-resolution methods, let’s look at how a client computer in an NT network might go about resolving a NetBIOS name, using Figure 6.6 as a reference (here, the term client refers to any computer that needs to resolve a name).
First, you need to understand that NT clients approach NetBIOS name resolution in several ways: broadcasts, point-to-point queries, and WINS server queries. Depending on the type of resolution a computer uses, it is called a B, P, M, or H node.
All four node types first check the local NetBIOS name cache. If they find a match for the NetBIOS name, they return the IP address. If a match isn’t found, each node type approaches the next step in resolving a name differently.
B (broadcast) nodes next use broadcast messages for name resolution.
P (point-to-point) nodes next use point-to-point queries to a WINS server to resolve NetBIOS names.
M (mixed) nodes next use broadcasts for name resolution, but if that fails, they query a WINS server.
H (hybrid) nodes next look for a WINS server; if one is not available or fails to produce a match, they use a broadcast to resolve names.
Special Note: You can examine the contents of the NetBIOS name cache by typing the nbtstat -c command at a DOS command prompt. Figure 6.7 shows an example of the results.
This command provides the name, type of name, host address, and life in seconds for each NetBIOS name loaded into the name cache. Life [sec] refers to the number of seconds left for that name in the local name cache. The NetBIOS name is usually kept in the local cache for about 10 minutes. If it is not reused within that period, it expires from the cache. If the name is preloaded using a #PRE entry in the LMHOSTS file, it stays in the cache until the machine is powered down. In this example, the name SBS01 has been preloaded using the LMHOSTS file. The sample LMHOSTS file (lmhosts.sam), provides a detailed description of all entries and is available in the %systemroot%\system32\drivers\etc folder.
If these methods are unsuccessful and “Enable LMHOSTS Lookup” is checked, as shown in Figure 6.6, all four node types look at the LMHOSTS file for the entries that weren’t preloaded into the NetBIOS name cache. If that search fails, the client then looks at the HOSTS file. If the client is still not successful, it uses DNS to resolve the name.
Special Note: The order in which name resolution methods are used depends on whether a computer is configured as a B, P, M, or H node. While the administrator can manipulate the configuration and, thus, exercise limited control over the order of the name resolution methods used, in most instances, an administrator may not control the name resolution scheme because it may simply be impractical to modify Registry entries related to name resolution on all clients. In essence, the system tries whatever methods are available to resolve the name in a process transparent to the user and administrator.
Name Resolution at a Glance
A client computer configured to use WINS, LMHOSTS files, a HOSTS file, and DNS follows this series of steps to resolve a NetBIOS name:
NetBIOS name cache — A client first queries the local NetBIOS name cache. NetBIOS names and IP addresses are preloaded into the name cache when a #PRE entry for the names and IP addresses appears in the LMHOSTS file.
WINS server — If the unresolved NetBIOS name isn’t found in the name cache, NT tries to locate that name using a WINS server.
Broadcasts within an IP subnetwork — If the name cache and WINS server aren’t available or fail to produce a match, the client typically tries a broadcast to the other computers in the network.
LMHOSTS file(s) — If a broadcast fails to resolve the name and “Enable LMHOSTS Lookup” is checked, the client looks at the LMHOSTS file for the entries that weren’t preloaded into the NetBIOS name cache.
HOSTS file — If the LMHOSTS file search fails, the client then looks at the HOSTS file.
DNS server — If “Enable DNS for Windows Resolution” is checked, the client queries the DNS server, which returns the IP address.
Knowing the order of name resolution methods will help you optimize access to resources. For example, because the NetBIOS name cache is queried first, you could consider using a #PRE entry in the LMHOSTS file to statically add the NetBIOS name and IP address of a computer you communicate with often. Similarly, using a WINS server from a local network or a network that has higher bandwidth will help you resolve NetBIOS over TCP/IP more quickly.
Host name resolution is a lot simpler. When an application needs to resolve a host name, the process is quite similar to that in Unix. The HOSTS file is referenced and if an IP address can’t be resolved from the HOSTS file, NT looks for help from a DNS server (if configured in the TCP/IP configuration parameters). As we explain later, DNS servers running on NT can be configured to use WINS servers. If WINS lookup is enabled, the DNS server tries to resolve the name from the WINS server and returns the IP address to the client.
B and P Node Considerations
Using B node and P node mechanisms in the same network is not a good practice. A P node never listens to broadcasts for either name resolution or registration; and because B nodes use broadcasts exclusively, it is possible for a P node to have the same name as a B node but never acknowledge the fact. Two computers or resources with the same name will cause problems.
Performance problems are associated with both B nodes and P nodes. Because routers usually don’t forward broadcast messages, it is impossible for B nodes to locate NetBIOS names across routers unless the LMHOSTS file is configured properly. You must make sure that the NetBIOS names and IP addresses are entered correctly in the LMHOSTS files on all client computers.
A P node may be slow to resolve names if the WINS server it needs to use is located across a router. Also, if the WINS server is unavailable, name resolution fails on the P node. Another problem with P nodes is that the entry for the WINS server must be configured either manually or through a DHCP server. Switching WINS servers from one network to another or modifying the IP address of a WINS server in a large network can be a complex process.
Both B and P node behavior with NetBIOS over TCP/IP can be altered by modifying certain Registry entries. The entries and values are found in the following subkey and are explained in Table 6.3.
Special Note: You may see the terms NetBEUI, NBF, NetBIOS Frame, and NetBEUI Frame used almost interchangeably in various pieces of documentation. NetBIOS is the API, whereas NetBEUI is the network protocol that works well on LANs — single networks that do not need any routing capabilities.
When you hear someone say that NetBEUI is not routable, that is true. If you hear that NetBIOS is not routable, that is false.
NetBIOS had a limitation of 254 connections per network member — client as well as server. Microsoft enhanced NetBIOS so that you could run multiple processes simultaneously and each process could have up to 254 connections. This enhanced NetBIOS is called NetBIOS Frame (NBF). Articles in the trade press and Microsoft white papers also refer to NetBIOS Frame as NetBEUI Frame. Technically, the correct term is NetBIOS Frame.
Registry entries for NetBIOS Frame (NBF) are found in the following subkey and explained in Table 6.4.
M and H Node Considerations
Recall that M nodes attempt to resolve a name first with a broadcast and then with a point-to-point query to a WINS server. Because local resources are used more frequently than remote resources, performance for a LAN is optimized.
Also recall that H nodes attempt to query a WINS server first, and if the query fails, they then use a broadcast. If both the target computer (the computer whose name you’re trying to resolve) and the WINS server are on the other side of a router from the client, resolution speed is relatively quick because no time or bandwidth is wasted by broadcasting. If the target computer is on the same local subnetwork as the client while the WINS server is on the other side of the router, however, resolution speed can be relatively slow because the resolution process has to cross the router twice. If the WINS server is on the other side of the router and is unavailable, for whatever reason, and the point-to-point approach fails, an H node resorts to a broadcast. So, name resolution on H nodes within the local network is not affected if the WINS server has problems.
If an H node can’t find a WINS server during a name resolution request, the H node continues to check periodically for its existence, using broadcasts until the WINS server is available. As soon as it receives a response from the WINS server, it reverts to using the WINS server first for name resolution. If a WINS server is specified in the Network parameters, the H node process is used by default. If a WINS server is not specified, the broadcast method is used. If a WINS server is on the other side of a router, name resolution within the local network is not affected.
Some of the Registry parameters that affect M node and H node behavior are found in the following Registry subkey:
You can change four values — DnsPriority, LocalPriority, HostsPriority, and NetbtPriority — to change the order in which the name resolution methods occur (Figure 6.8).
In Figure 6.8, the value of Class is shown as 8, which indicates that we are dealing with an H node. (The Class value for B node is 1, for P node is 2, and for M node is 4.) The current priority values are
Local cache — 499
HOSTS file — 500
DNS — 2000
NetBIOS over TCP/IP —2001
The lower the number, the higher the priority. For example, if you wanted DNS to have the highest priority — perhaps, you have a fast DNS server or are using dynamic DNS — you should use a number smaller than 499 for DnsPriority. Changing this value changes the order of name resolution methods used so that DNS is used first for locating the resource.
If you do make such a change and depend on DNS for name resolution, make sure that the Ancillary Function Driver (AFD.SYS) is not disabled or shut down. (The AFD.SYS file extends the Transport Driver Interface (TDI) by providing kernel mode support for Windows Sockets. If AFD.SYS is disabled or shutdown, DNS resolution will not work.)
DNS IN DEPTH
In the previous sections, we looked at the NetBIOS and host name resolution process and discussed the mechanics of name resolution. Because NetBIOS name resolution methods and host name resolution methods are used (in different order) for resolving NetBIOS and host names, here, we look at how to configure DNS to address the name resolution issues we have discussed so far. Because the Active Directory feature in Windows 2000 Server uses DNS as a locator service, you may want to implement DNS in your network even if you are not connected to the Internet. Configuring DNS, especially using the Domain Name Service Manager (DNS Manager — new with NT 4.0), is relatively straightforward.
The first time you bring up DNS Manager, you need to register the IP addresses of any DNS servers you want to administer. To do so, select New Server from the DNS menu and enter the IP addresses for each DNS server.
Then you need to create zones to include all the computers that can be resolved by a particular DNS server. Finally, you need to create the appropriate resource records for each zone.
WinConnections Conference Fall 2008 Don’t miss the premier event for Microsoft IT Professionals in Las Vegas, November 10-13. Register and book your room by August 25 and receive a FREE room night (based on a three night minimum stay).
Master SharePoint with 3 eLearning Seminars Learn how to build a better SharePoint infrastructure and enable powerful collaboration with MVPs Dan Holme and Michael Noel. Register today!
SharePointConnections Conference Fall 2008 Don’t miss the premier event for Microsoft IT Professionals in Las Vegas, November 10-13. Register and book your room by August 25 and receive a FREE room night (based on a three night minimum stay).
VMworld 2008 - Sign Up Today! Join your peers on September 15-18 at The Venetian Hotel in Las Vegas as VMware hosts VMworld 2008, the leading Virtualization event.
Microsoft® Tech•Ed EMEA 2008 IT Professionals Advance your thinking with new ideas and practical real-world solutions at Microsoft’s FIVE day technical infrastructure conference 3-7 Nov., 2008. Register before 26 September 2008 to save €300.
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Are You Really Compliant with Software Regulations? View this web seminar that will help you with compliance best practices and check out a management solution to assure that you won’t be in jeopardy of an audit.
Virtualization Congress Oct. 14-16 in London Don't miss Virtualization Congress, the premiere EMEA conference dedicated to hardware, OS and application virtualization. Oct. 14-16 in London.
Windows IT Pro
Register
