On TCP/IP networks, the ultimate goal of NetBIOS name resolution is to provide an IP address for a given NetBIOS name.
Technically there are 16 characters in a NetBIOS name. However, the sixteenth character is used by the underlying application, and in general is not directly configurable by the
. These characters are discussed later in this
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
One way for name resolution to take place is through broadcasts. A
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.
By the Way
Broadcasts can produce a great deal of network traffic, which can be disruptive to the network. Routers limit this disruption by not forwarding broadcasts to the rest of the network.
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
file (described earlier in this hour). An LMHosts file
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
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
. You can edit the
file, but you must drop the
extension before the file is usable.
By the Way
The LM in LMHosts is a holdover from Microsoft's LAN Manager, a networking product that predates Windows NT.
The following is an example of what a basic LMHosts file looks like:
126.96.36.199 marketserv #file server for marketing department
188.8.131.52 marketapp #application server for marketing
184.108.40.206 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
name. This can be a
process if there are many entries in the LMHosts file, so to speed up the process you can
certain high-use entries to be preloaded into the NetBIOS name cache by including the
keyword (see Figure 11.9). The LMHosts file is scanned once in its entirety when networking starts, so for efficiency the lines that include
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.
Figure 11.9. Contents of an LMHosts file.
By the Way
You can use the NBTStat utility to view and manipulate the NetBIOS name cache. To view the contents of the cache, type
at the command prompt.
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
followed by an entry for the
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
entry, they need to be placed between the keywords
, 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
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.
By the Way
WINS is the name assigned to Microsoft's implementation of what is generically known as a NetBIOS name server or NBNS. NetBIOS name servers are described in RFCs 1001 and 1002.
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
, 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
(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.
Figure 11.10. WINS NetBIOS name resolution.
By the Way
Microsoft introduced a form of DNS/WINS integration with Windows NT 4 that provided DNS name resolution over a larger network combined with automatic NetBIOS resolution. The further integration of DNS with NetBIOS in the Windows 2000 Active Directory environment makes this feature largely unnecessary.
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
a WINS client.
When a WINS client computer boots after being configured to use WINS, the following process occurs:
- As the computer boots, various services are started, some of which need to be made known to other computers.
- To be known to other computers on the network, the service must register itself. A WINS client computer packages the NetBIOS name and the computer's IP address inside a name registration request, and the registration request is sent to the WINS server. Upon receiving the registration request, WINS checks its database to see whether the name is already registered.
If the name does not exist, WINS adds the NetBIOS name and IP address pair to its database and sends a name registration response indicating the name was successfully registered. If the requested NetBIOS name already exists in the WINS database, WINS challenges the computer currently registered by sending a message to the registered IP address. If the currently registered computer responds, a negative
is sent to the computer attempting to register the name. If the computer being challenged doesn't respond, WINS allows the registration to occur and overwrites the previous registration.
- Assuming the computer is successful in registering its NetBIOS names and services with WINS, these names are considered leased. In essence, the computer is allowed to use the NetBIOS name for a specified period of time -for instance six days -but the client can renew the lease before it
. The client typically renews the lease at 50% of the total lease time or in this case every three days.
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
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
to name resolution.