Methods for NetBIOS Name Resolution

On TCP/IP networks, the ultimate goal of NetBIOS name resolution is to provide an IP address for a given NetBIOS name.

NetBIOS names are single names up to 15 characters in length, such as Workstation1, HRServer, and CorpServer. NetBIOS does not allow for duplicate computer names on a network.

NetBIOS names, like hostnames, are said to be in a flat namespace, because there is no hierarchy or capability to qualify the names. In the following sections, you will examine several ways to resolve NetBIOS names to their corresponding IP addresses:

• Broadcast-based name resolution

• LMHosts filename resolution

• WINS name resolution

Broadcast-Based Name Resolution

One way for name resolution to take place is through broadcasts. A broadcast occurs when a computer announces to all the other machines on its network segment that it needs the address of a particular computer. All the computers on the segment hear the broadcast, but only the machine specified in the broadcast responds to the request.

This method of name resolution, also known as B-Node name resolution, works well in a LAN environment but does not work in networks that extend beyond the LAN, because routers block broadcasts by design.

The broadcast name resolution process is simple and requires no extra configuration to set up or use. Simply installing a network card and TCP/IP networking software onto a Windows operating system enables these systems to use broadcasts to locate other computers through NetBIOS name resolution.

LMHosts Files Name Resolution

Windows systems can also resolve NetBIOS names to IP addresses using the LMHosts file. The LMHosts file is similar to the hosts file (described earlier in this hour). An LMHosts file associates NetBIOS names to IP addresses. The IP address is listed in the left column of the file with the corresponding computer name to the right separated by at least one space; comments can be put in the file by placing them after a # character. LMHosts requires a static mapping of IP addresses to NetBIOS names. A separate LMHosts file resides on each computer. You have to manually configure the LMHosts file. If a new computer is added to the network, the other computer will not be able to find it through LMHosts until an entry for that computer is manually added to each LMHosts file.

On a network consisting of a single segment, an LMHosts file is usually not necessary, because computers on the network can resolve NetBIOS names through broadcast. (In some cases, LMHosts can be used for efficiency or for compatibility with older, nonbroadcasting systems.) On larger networks consisting of more than one segment, broadcast cannot be used to resolve names beyond the router. In that case, computers must perform NetBIOS name resolution using either LMHosts or a WINS server (described in the next section). In some cases, LMHosts is useful for pointing the way to a domain controller on a different network segment. (A domain controller is necessary for authentication in a domain-based Windows environment.)

On Windows systems, the LMHosts file is included with Microsoft TCP/IP. Microsoft also includes a sample LMHosts file named LMHosts.sam. You can edit the LMHosts.sam file, but you must drop the .sam extension before the file is usable.

The following is an example of what a basic LMHosts file looks like:

192.59.66.205    marketserv    #file server for marketing department
192.59.66.206    marketapp    #application server for marketing
192.59.66.207    bobscomputer    #bob's workstation

Recently resolved NetBIOS names are stored in the NetBIOS name cache. As you learned in Hour 16, "The Internet: A Closer Look," a cache is part of a computer's memory that keeps frequently requested data in memory and ready to be accessed. Whenever a user attempts to locate a specific computer, the system always consults the NetBIOS name cache before searching the LMHosts file. If no match is found, the entries within the LMHosts file can then be scanned for the requested name. This can be a time-consuming process if there are many entries in the LMHosts file, so to speed up the process you can designate certain high-use entries to be preloaded into the NetBIOS name cache by including the #PRE keyword (see Figure 11.9). The LMHosts file is scanned once in its entirety when networking starts, so for efficiency the lines that include #PRE keywords are usually placed toward the bottom of the LMHosts file. These lines need to be read only once, and placing them later in the file lessens the chance that they will be reread.

Maintaining static files such as hosts and LMHosts is difficult because these files are located on each individual computer, and therefore are not centralized. The LMHosts file addresses this problem by using the keyword #INCLUDE followed by an entry for the path to LMHosts files on other machines. With this keyword, the local LMHosts file can include the location of a server-based LMHosts file for use by the local machine. This enables edits to be performed on the server-based LMHosts file, but the changes are accessible from the user's computer.

If there is more than one #INCLUDE entry, they need to be placed between the keywords #BEGIN ALTERNATE and #END ALTERNATE, as shown in Figure 11.9.

As mentioned previously, LMHosts can be used to locate a Windows domain controller on a different network segment. The #DOM keyword identifies an LMHosts entry that represents a domain controller.

Windows Internet Name Service (WINS) Name Resolution

Windows Internet Name Service (WINS) was created to address the same types of shortcomings in LMHosts that DNS was created to address regarding hosts files. When a client needs to get the IP address for a computer, it can query the WINS server for the information.

WINS maintains a database of registered NetBIOS names for a variety of objects, including users, computers, services running on those computers, and workgroups. However, instead of the entries in this database coming from manually edited text files, as in most DNS implementations, a client computer registers its name and IP address with the WINS server dynamically when it starts up.

The WINS server receives and responds to NetBIOS name resolution requests (see Figure 11.10). If the WINS server in Figure 11.10 looks similar to the DNS server in Figure 11.2, that's because it is. A WINS server does for NetBIOS name resolution what the DNS server does for domain name resolution. However, the flat NetBIOS namespace provides no equivalent to the hierarchical name resolution techniques available through DNS.

To configure a Windows computer to use WINS, you enter the IP address of one (or two) WINS server in the WINS Address Property tab or the TCP/IP Properties dialog box. After this is finished and the computer has rebooted, it is now considered a WINS client.

When a WINS client computer boots after being configured to use WINS, the following process occurs:

Earlier I noted that the 16th character of a NetBIOS name is not configurable by the user. During the WINS registration process, the 16th character is appended to the name by the WINS server based on what type of service the computer is trying to register before it is placed in the database. Between computer names, workgroup names, and a number of services, it is not unusual for a single computer to have 5 to 10 registration entries in the WINS database.

As another example of the WINS name resolution process, suppose a user on a computer uses a utility such as Network Neighborhood to connect to another computer on the network. A name query request, which includes the desired NetBIOS name, is constructed by the application and sent to the WINS server. When WINS receives the request, it queries its database for a matching registration. If the requested name is found, WINS returns the corresponding IP address in the response packet. After the client computer has the IP address for the requested computer, the client can then communicate directly.

One nice feature of WINS is that it works well in both local and remote networks and can be integrated with DNS. However, that discussion is beyond the scope of this book. What I have done here is given you a basic overview of WINS as it relates to name resolution.