Chapter 32 - Networking Name Resolution and Registration

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Administration of Microsoft TCP/IP and related services splits roughly into two functional areas:

• Client Configuration Options. Every computer on a TCP/IP internetwork must be given a unique computer name and IP address. The IP address identifies both the computer and the subnetwork to which it is attached. When the computer is moved to a different subnetwork, the IP address must be changed to reflect the new subnetwork ID. 

• Name Resolution Services. People use "friendly" names to connect to computers; programs use IP addresses. TCP/IP internetworks require a name resolution service that converts computer names to IP addresses and IP addresses to computer names. 

This chapter is intended for the administrator of small peer-to-peer workstation subnet, or single workstation environments, that connect to Internet or TCP/IP network resources. This information in this chapter is required knowledge for the following chapter "Using LMHOSTS Files".

Understanding IP Addressing

To receive and deliver packets successfully between computers, TCP/IP requires that each computer be configured with three values provided by the network administrator: an IP-address, a subnet mask, and a default gateway (router).

Note Users running Windows NT on networks with Windows NT Server-based DHCP servers can take advantage of automatic system configuration and do not need to manually configure a computer with these TCP/IP values.

IP Addresses

Every device attached to a TCP/IP network is identified by a unique IP address. (If a computer has multiple network adapters, each adapter will have its own IP address.) This address is typically represented in dotted-decimal notation, that is, with the decimal value of each octet (eight bits, or one byte) of the address separated by a period. Here is a sample IP address:

138.57.7.27

Important Because IP addresses identify devices on a network, each device on the network must be assigned a unique IP address.

Network ID and Host ID

Although an IP address is a single value, it contains two pieces of information: the network ID and the host ID of your computer.

• The network ID identifies the systems that are located on the same physical network. All systems on the same physical network must have the same network ID, and the network ID must be unique to the internetwork.

• The host ID identifies a workstation, server, router, or other TCP/IP device within a network. The address for each device must be unique to the network ID.

A computer connected to a TCP/IP network uses the network ID and host ID to determine which packets it should receive or ignore and to determine the scope of its transmissions. (Only computers with the same network ID accept each other's IP-level broadcast messages.)

Note Networks that connect to the public Internet must obtain an official network ID from the Internet Network Information Center (InterNIC) to guarantee IP network ID uniqueness. For more information, visit the InterNIC home page on the Internet at: https://www.internic.net/

After receiving a network ID, the local network administrator must assign unique host IDs for computers within the local network. Although private networks not connected to the Internet can use their own network (intranet) identifier, obtaining a valid network ID from InterNIC allows a private network to connect to the Internet in the future without reassigning addresses.

The Internet community has defined address classes to accommodate networks of varying sizes. The address class can be discerned from the first octet of an IP-address. Table 32.1 summarizes the relationship between the first octet of a given address and its network ID and host ID fields. It also identifies the total number of network IDs and host IDs for each address class that participates in the Internet addressing scheme. This example uses w.x.y.z to designate the bytes of the IP address.

Class	w values 1,2	Network ID	Host ID	Available networks	Available hosts per network
A	1–126	w	x.y.z	126	16,777,214
B	128–191	w.x	y.z	16,384	65,534
C	192–223	w.x.y	z	2,097,151	254

1 Inclusive range for the first octet in the IP address. 

2 The address 127 is reserved for loopback testing and interprocess communication on the local computer; it is not a valid network address. Addresses 224 and above are reserved for special protocols (Internet Group Management Protocol multicast and others) and cannot be used as host addresses. 

Subnet Masks

Subnet masks are 32-bit values that allow the recipient of IP packets to distinguish the network ID portion of the IP address from the host ID. Subnet masks are created by assigning 1's to network ID bits and 0's to host ID bits. The 32-bit value is then converted to dotted-decimal notation, as shown in Table 32.2.

Address class	Bits for subnet mask	Subnet mask
Class A	11111111 00000000 00000000 00000000	255.0.0.0
Class B	11111111 11111111 00000000 00000000	255.255.0.0
Class C	11111111 11111111 11111111 00000000	255.255.255.0

For example, when the IP address is 138.57.7.27 and the subnet mask is 255.255.0.0, the network ID is 138.57 and the host ID is 7.27.

Because the class of a host is easily determined, configuring a host with a subnet mask might seem redundant. But subnet masks are also used to further segment an assigned network ID among several local networks. Sometimes only portions of an octet need to be segmented using only a few bits to specify subnet IDs.

Important To prevent addressing and routing problems, all computers on a logical network must use the same subnet mask and network ID.

IP Routing

The Internet and other TCP/IP networks are interconnected by routers, which are devices that pass IP packets from one network to another.

For each computer on an IP network, you can maintain a table with an entry for every other computer or network with which the local computer communicates. In general, this is not practical, and the default gateway (router) is used instead. (The default gateway is a computer connected to the local subnet and to other networks. It has knowledge of the network IDs for other networks in the internetwork and how to reach them. It is needed only for computers that are part of an internetwork.)

When IP prepares to send a packet, it inserts the local (source) IP address and the destination address of the packet in the IP header. It then examines the destination address, compares it to a locally maintained route table, and takes appropriate action based on what it finds. There are three possible actions:

• It can pass the packet up to a protocol layer above IP on the local host.

• It can be forwarded through one of the locally attached network adapters.

• It can be discarded.

The search for a match of the destination address in the route table proceeds from the specific to the general in the following order:

• The table is examined for an exact match (host route).

• The host portion is stripped from the destination address, and the table is examined for a match (subnet route).

• The subnet portion is stripped from the destination address, and the table is examined for a match (network route).

• The default gateway is used.

• If a default gateway has not been specified, the packet is discarded.

Because the default gateway contains information about the network IDs of the other networks in the internetwork, it can forward the packet to other routers until the packet is eventually delivered to a router connected to the specified destination. This process is known as routing and is illustrated in Figure 32.1.

 

Figure 32.1 Routers (default gateway) 

Note If the default gateway becomes unavailable, communication beyond the local subnet can be impaired. To prevent this, use the Network application in Control Panel to specify multiple default gateways, or use the route utility to manually add routes to the route table for heavily used systems or networks.

IP Addressing for RAS

Remote dial-in access to internetworks is provided by a built-in feature of Windows NT known as Remote Access Service (RAS). RAS is based on a client-server architecture in which a remote RAS-based client connects to a local RAS server. After the connection has been made, the client running RAS becomes a full-fledged host on the network, and the remote user can then use the same Windows-based tools as a local user to access resources such as files, printers, electronic mail, and databases.

As shown in Figure 32.2, RAS supports multiple protocols, two of which are TCP/IP over Point-to-Point Protocol (PPP), and Serial Line IP (SLIP). Such protocol support allows a client with a RAS connection to interoperate with the heterogeneous servers typically found on today's internetworks.

 

Figure 32.2 Network Access with RAS in Windows NT 

Client configuration options are handled directly by the RAS server. The RAS server reserves a pool of IP addresses for static configuration during RAS installation. These addresses are automatically assigned to RAS clients who dial in using PPP. If the administrator sets up the RAS server to use a static pool of addresses, all clients dialing into a particular RAS server are assigned the same network ID as the RAS server, plus unique host IDs. Clients running RAS can use the same name resolution services as hosts connected directly to the internetwork.

Name Resolution Services

Windows NT with TCP/IP requires a unique IP address and computer name for each computer on the network. A mechanism must be available on a TCP/IP network to match computer names to IP addresses. These are called name resolution services.

Background

As networks have grown in complexity, so have these name resolution mechanisms increased in sophistication.

NetBIOS and DNS Computer Names

Windows NT networking components rely on a naming convention known as NetBIOS. In general, NetBIOS computer names consist of a single part.

In contrast, TCP/IP components rely on a naming convention know as the Domain Name System (DNS). DNS computer names consist of two parts: a host name and a domain name, which combined form the fully qualified domain name (FQDN).

Fortunately, NetBIOS computer names are compatible with DNS host names, making interoperation possible between the two. Windows NT combines the NetBIOS computer name with the DNS domain name to form the FQDN.

Note Under Windows NT, the DNS host name defaults to the same name as the NetBIOS computer name. You can change this if you need separate names.

Flat vs. Hierarchical Name Spaces

The original naming scheme for both NetBIOS and TCP/IP consisted of a flat name space where each computer was assigned a single-part name. (A single-part name consists of a short sequence of characters without any additional structure.) Flat name spaces worked well for simple networks with relatively few interconnected computers, but as network complexity increased, they rapidly become inadequate for the following reasons:

• Single-part names are derived from a finite set of identifiers. The potential for conflict increases with the number of computers interconnected.

• Administration of the name space rests with a central authority. Someone must ensure that each computer is assigned a unique name. Because there is no convenient way to segment a flat name space, control of name assignment must be centralized.

• All changes to the network must be approved by the central authority. Before a new computer is added to the network or an existing computer is moved to a different subnet, the change must be coordinated with the central authority. For a large network, this results in a significant administrative burden.

A hierarchical name space implemented as a multi-part naming scheme enables authority to be distributed and administration to be decentralized. A hierarchical name space can be viewed as an inverted tree with the branches and leaves pointing down. A central authority still manages the top of the tree, but below the top level the structure can be distributed into autonomous administrative units. Name uniqueness must still be enforced at the lowest administrative level, but this is a reasonable task for a well-segmented name space. The hierarchical structure of the name space guarantees name uniqueness above these lower levels.

Implementations of hierarchical naming schemes exist for both TCP/IP and NetBIOS: Domain Name System (DNS) for TCP/IP and NetBIOS Scope for NetBIOS.

Name Space Implementations

The first implementations of name spaces — both flat and hierarchical — relied on text files for mapping of computer name to IP address. Each computer on the internetwork had its name and IP address on a line in the file, and a copy of the file existed on each computer. This solution worked well for simple networks having relatively few interconnected computers. As networks grew in size and complexity, this method ran into scaling problems similar to those experienced with a flat name space.

Newer implementations have largely done away with the need for a mapping file on each machine; instead, server-based repositories store the necessary information. Mapping files still exist but are typically used in simple networks or as a safety feature in case the name servers are down.

The mapping files are

• HOSTS for DNS names

• LMHOSTS for NetBIOS names

Note When you install Windows NT, example HOSTS and LMHOSTS files are placed in the \systemroot\System32\Drivers\Etc directory.

NetBIOS over TCP/IP (NetBT) Name Resolution

Name resolution services for Windows NT fall into two general categories. Each provides similar services for clients and can operate independently or in tandem. They are

• NetBIOS over TCP/IP (NetBT)

• Domain Name System (DNS)

NetBT is the session-layer network service that performs name-to-IP address mapping for name resolution. Under Windows NT, it is implemented through the broadcast name resolution and Windows Internet Name Service (WINS) (on those networks with WINS servers). The two most important aspects of the related naming activities are registration and resolution:

• Registration is the process used to register a unique name for each computer (node) on the network. A computer typically registers itself when it starts.

• Resolution is the process used to determine the specific address for a computer name.

Note RFCs 1001 and 1002 specify how NetBIOS should be implemented over TCP/IP and define the name resolution modes.

Defined within NetBT are modes that specify how network resources are identified and accessed. The most common NetBT modes are

• b-node, which uses broadcast messages to resolve names

• p-node, which uses point-to-point communications with a name server to resolve names

• m-node, which first uses b-node and then — if necessary — p-node to resolve names

• h-node, which first uses p-node for name queries and then b-node if the name service is unavailable or if the name is not registered in the database

The two most common node types for client computers running Windows NT are h-node and b-node. The default node type is b-node.

Note If the Windows NT Workstation computer can access a DHCP server or WINS server, the node type is assigned by the DHCP server. If the client computer is configured to use WINS, Windows NT defaults to h-node.

In Windows NT, the Netbt.sys module provides the NetBT functionality that supports name registration and resolution modes. NetBT uses b-node broadcast messages to resolve names. NetBT can also use LMHOSTS files and DNS for name resolution, depending on how TCP/IP is configured on a particular computer.

Note When WINS servers are in place on the network, NetBT resolves names on a client computer by communicating with the WINS server, before using LMHOSTS files.

Windows NT supports all NetBT modes described in the following sections. NetBT is also used with the LAN Manager 2.x Server message protocol.

B-Node

The b-node mode uses broadcast messages for name registration and resolution. For example, if a computer named NT_PC1 wants to communicate with a computer named NT_PC2, NT_PC1 sends a broadcast message that it is looking for NT_PC2, and then it waits a specified time for NT_PC2 to respond.

B-node has two major problems:

• In a large environment, it loads the network with broadcast messages.

• Typically, routers do not forward broadcast messages, so computers on opposite sides of a router never hear the requests.

P-Node

The p-node mode addresses the issues that b-node does not solve. In a p-node environment, computers neither create nor respond to broadcast messages. All computers register themselves with the WINS server, which is responsible for knowing computer names and addresses and for ensuring that no duplicate names exist on the network.

In this environment, when NT_PC1 wants to communicate with NT_PC2, it queries the WINS server for the address of NT_PC2. Upon receipt of the address, NT_PC1 goes directly to NT_PC2 without broadcasting. Because the name queries go directly to the WINS server, p-node avoids loading the network with broadcast messages. Because broadcast messages are not used, and because the address is received directly, computers can be on opposite sides of routers.

The most significant problems with p-node are the following:

• All computers must be configured to know the address of the WINS server.

• If the WINS server is down, computers that rely on it to resolve addresses cannot get to any other systems on the network.

M-Node

The m-node mode was created primarily to solve the problems associated with b-node and p-node. In an m-node environment, a computer first attempts registration and resolution using b-node. If that fails, it switches to p-node. Advantage are as follows:

• M-node can cross routers.

• Because b-node is always tried first, computers on the same side of a router continue to operate as usual if the WINS server is down.

• In theory, it should increase local area network (LAN) performance.

H-Node

The h-node mode solves the most significant problems associated with broadcast messages and with routed-environment operations. It is a combination of b-node and p-node that uses broadcast messages as a last effort. The h-node mode does more than change the order for using b-node and p-node: If the WINS server is down — making broadcast messages a necessity — the computer continues to poll the WINS server. When the WINS server can be reached again, the system returns to p-node. H-node can also be configured to use the LMHOSTS file after broadcast name resolution fails.

Because p-node is used first, no broadcast messages are generated if the WINS server is running, and computers can be on opposite sides of routers. If the WINS server is down, b-node is used, so computers on the same side of a router continue to operate as usual.

Other Combinations

Another variation, known as modified b-node, is also used in Microsoft networks so that messages can go across routers. Modified b-node does not use p-node mode or a WINS server. In this mode, b-node uses a list of computers and addresses stored in an LMHOSTS file. If a b-node attempt fails, the system looks in LMHOSTS to find a name and then uses the associated address to cross the router. However, each computer must have this list, which creates an administrative burden in maintaining and distributing the list. Both Windows for Workgroups 3.11 and LAN Manager 2.x used such a modified b-node system. Windows NT uses this method if WINS servers are not used on the network. In Windows NT, some extensions have been added to this file to make it easier to manage (as described in the* *"Using LMHOSTS Files" chapter in this book), but modified b-node is not an ideal solution.

Some sites might require both b-node and p-node modes. Although this configuration can work, administrators must exercise extreme caution, using it only for transition situations. Because p-node hosts disregard broadcast messages, and b-node hosts rely on broadcast messages for name resolution, the two hosts can potentially be configured with the same NetBIOS name, leading to unpredictable results. Also, if a computer configured to use b-node has a static mapping in the WINS database, a computer configured to use p-node cannot use the same computer name.

Computers running Windows NT can be configured as WINS proxy agents to help the transition to using WINS. Windows-based networking clients (WINS-enabled Windows NT, Windows 95, or Windows for Workgroups 3.11 computers) can use WINS directly. Non-WINS computers that are b-node compatible (as described in RFCs 1001 and 1002) can access WINS through proxies. A WINS proxy is a WINS-enabled computer that listens for name-query broadcast messages and then respond for names that are not on the local subnet. Proxies are p-node computers.

Figure 32.3 shows a small internetwork with two local area networks connected by a router. One of the subnets has a WINS name server, which can be used by clients on both subnets. The WINS proxy computer (which must be WINS by using TCP/IP Configuration), can access the WINS server directly. The name registration and resolution broadcasts from the non-WINS enabled computers are intercepted by the WINS proxy. Proxies intercept the broadcast messages and send them directly to the WINS server on the other sub-net.

 

Figure 32.3 Routed Network with WINS Server 

In a WINS and broadcast name resolution environment, a WINS-enabled client computer will behave differently than a non-WINS-enabled client computer. These differences will be apparent in the way these clients handle resolution, registration, release, and renewal.

Name Resolution

NetBIOS computer names are resolved using two basic methods, depending on whether WINS resolution is available and enabled on the client computer. Whatever name resolution method is used, the process is transparent to the user after the system is configured.

If WINS is not enabled on the client: The computer registers its name by sending name registration request packets (as broadcast messages) to the local subnet. To find a particular computer, the non-WINS computer sends name query request packets (as broadcast messages) on the local subnet. (This broadcast message cannot be passed on through IP routers.) If local name resolution fails, the local LMHOSTS file is consulted. These processes are followed whether the computer is a network server, a workstation, or other device.

If WINS is enabled on the client: The computer first queries the WINS server. If that fails, it sends name registration and query requests (as broadcast messages).

Name Registration

Name registration ensures that the NetBIOS computer name and IP address are unique for each device.

If WINS is not enabled on the client: For a non-WINS computer to register its name, a name registration request packet is broadcast to the local network, stating its NetBIOS computer name and IP address. Any device on the network that previously claimed that name challenges the name registration (with a negative name registration response), resulting in an error for the computer attempting to register the duplicate name. If the name registration request remains unchallenged for a specific time period, the requesting computer adopts that name and address.

After a non-WINS computer claims a name, it must challenge duplicate name registration attempts (with a negative name registration response) and respond positively to name queries issued on its registered name (with a positive name query response). The positive name query response contains the IP address of the computer so that the two systems can establish a session.

If WINS is enabled on the client: The name registration request is sent directly to the WINS server to be added to the database. A WINS server accepts or rejects a computer name registration depending on the current contents of its database:

• If the database contains a different address for that name, WINS challenges the current entry to determine whether that device still claims the name.

• If another device is using that name, WINS rejects the new name registration request.

• Otherwise, WINS accepts the entry and adds it to its local database together with a timestamp, an incremental unique version number, and other information.

Name Release

When a computer finishes using a particular name (such as when the Windows NT Workstation service or Server service is stopped), it no longer challenges other registration requests for the name. This is referred to as releasing a name.

If WINS is not enabled on the client: When a non-WINS computer releases a name, a broadcast is made to allow any systems on the network that might have cached the name to remove it. Upon receiving name query packets specifying the deleted name, computers simply ignore the request, allowing other computers on the network to acquire the released name.

For non-WINS computers to be accessible from other subnets, their names must be added as static entries to the WINS database or in the LMHOSTS file(s) on the remote system(s), because they will respond only to those name queries that originate on their local subnet.

If WINS is enabled on the client: Whenever a computer is shut down properly, it releases its name to the WINS server, which marks the related database entry as released. If the entry remains released* *for a certain period of time, the WINS server marks it as extinct, updates the version number, and notifies other WINS servers of the change.

• If a name is marked released at a WINS server, and a new registration arrives using that name but a different address, the WINS server can immediately give that name to the requesting client because it knows that the old client is no longer using that name. This might happen, for example, when a DHCP-enabled laptop changes subnets.

• If the computer released its name during an orderly shutdown, the WINS server does not challenge the name when the computer is reconnected. If an orderly shutdown did not occur, the name registration with a new address causes the WINS server to challenge the registration. The challenge fails and the registration succeeds, because the computer no longer has the old address.

Domain Name System Name Resolution

The Domain Name System (DNS) is a distributed database providing a hierarchical naming system for identifying hosts on the Internet. DNS was developed to solve the problems that arose when the number of hosts on the Internet grew dramatically in the early 1980s. DNS specifications are defined in RFCs 1034 and 1035. Although DNS might seem similar to WINS, there is a major difference: WINS is fully dynamic, whereas DNS requires static configuration for computer name-to-IP address mapping.

The Domain Name Space

The DNS database is a tree structure called the domain name space. Each domain (node in the tree structure) is named and can contain subdomains. The domain name identifies the domain's position in the database in relation to its parent domain. A period (.) separates each part of the names for the network nodes of the DNS domain. For example, the DNS domain name csu.edu, specifies the csu subdomain whose parent is the edu domain; csu.com specifies the csu subdomain whose parent is the com domain. Figure 32.4 illustrates the parent-child relationships of DNS domains.

 

Figure 32.4 A Portion of the DNS Database 

As shown in Figure 32.4, the root node of the DNS database is unnamed (null). It is referenced in DNS names with a trailing period (.). For example, in the name: "research.widgets.com.", it is the period after com that denotes the DNS root node.

Top-Level Domains

The root and top-level domains of the DNS database are managed by the InterNIC. The top-level domain names are divided into three main areas:

• Organizational domains (3-character names)

• Geographical domains (2-character country codes found in ISO 3166)

• The in-addr.arpa. domain (a special domain used for address-to-name mappings)

Organizational domain names were originally used in the United States, but as the Internet began to grow internationally, it became obvious that an organizational division was inadequate for a global entity. Geographical domain names were then introduced. Even though a .us country domain exists, domain names in the United States are still predominantly organizational. As shown in Table 32.3, there are currently seven organizational domains.

DNS domain name abbreviation	Type of organization or institution
com	Commercial
edu	Educational
gov	Government
org	Noncommercial
net	Networking
mil	Military
int	International

Delegation

Responsibility for managing the DNS name space below the top level is delegated to other organizations by the InterNIC. These organizations further subdivide the name space and delegate responsibility down. This decentralized administrative model allows DNS to be autonomously managed at the levels that make the most sense for each organization involved.

Zones

The administrative unit for DNS is the zone. A zone is a subtree of the DNS database that is administered as a single separate entity. It can consist of a single domain or a domain with subdomains. The lower-level subdomains of a zone can also be split into separate zone(s). Figure 32.5 illustrates the relationship between DNS domains and zones.

 

Figure 32.5 DNS Zones 

Fully Qualified Domain Names

With the exception of the root, each node in the DNS database has a name (label) of up to 63 characters. Each subdomain must have a unique name within its parent domain. This ensures name uniqueness throughout the DNS name space. DNS domain names are formed by following the path from the bottom of the DNS tree to the root. The node names are concatenated, and a period (.) separates each part. Such names are known as fully qualified domain names (FQDN). Here's an example of one:

mrp2.widgets.mfg.universal.co.uk.

Note In practice, most DNS host entries appear no lower than the fifth level of the DNS tree, with three or four being more typical.

Name Resolution

The key task for DNS is to present friendly names for users and then resolve those names to IP addresses, as required by the internetwork. Name resolution is provided through DNS by the name servers, which interpret the information in a FQDN to find its specific address. As illustrated in Figure 32.6, the process begins when a resolver passes a query to its local name server. If the local name server does not have the data requested in the query, it queries other name servers on behalf of the resolver. In the worst-case scenario, the local name server starts at the top of the DNS tree with one of the root name servers and works its way down until the requested data is found.

 

Figure 32.6 DNS Name Resolution 

DNS name resolution consists of three key concepts: recursion, iteration, and caching.

• Recursion

  A resolver typically passes a recursive resolution request to its local name server. A recursive resolution request tells the name server that the resolver expects a complete answer to the query, not just a pointer to another name server. Recursive resolution effectively puts the workload onto the name server and allows the resolver to be small and simple.

• Iteration

  If the local name server cannot fully resolve the query, it enlists the aid of other DNS name servers throughout the DNS name space. A well-behaved local name server keeps the burden of processing on itself and passes only iterative resolution requests to other name servers. An iterative resolution request tells the name server that the requester expects the best answer the name server can provide without help from others. If the name server has the requested data, it returns it; otherwise it returns pointers to name servers that are more likely to have the answer. However, if a primary master name server is unable to resolve a request for data that should be in its zone, it returns an error to the requester.

• Caching

  As local name servers process recursive requests, they discover a lot of information about the DNS domain name space. To speed the performance of DNS and ease the burden on both the internetwork and the other name servers, local name servers temporarily keep this information in a local cache. Whenever a resolver request arrives, the local name server checks both its static information and the cache for an answer. Even if the answer is not cached, the identity of the name server for the zone might be, which reduces the number of iterative requests the name server has to process.

Note For more information about DNS see the Networking Guide for Microsoft Windows NT Server version 4.0 Resource Kit.

Name Resolution with Host Files

For computers located on remote subnets where WINS is not used, the HOSTS and LMHOSTS files provide mappings for names to IP addresses. This name-resolution method was used on internetworks before DNS and WINS were developed. The HOSTS file can be used as a local DNS equivalent; the LMHOSTS file can be used as a local WINS equivalent.

Note Sample versions of LMHOSTS and HOSTS files are added to the Windows NT \systemroot\System32\drivers\Etc directory when you install Microsoft TCP/IP.

HOSTS

Microsoft TCP/IP can be configured to search HOSTS (the local host table file) for mappings of remote host names to IP addresses. The HOSTS file format is the same as the format for host tables in the 4.3 Berkeley Software Distribution (BSD) UNIX /etc/hosts file. For example, the entry for a computer with an address of 192.102.73.6 and a host name of mfg1.widgets.com looks like this:

192.102.73.6 mfg1.widgets.com

You can create the file by using a text editor — for example, Notepad — to create, and change the HOSTS file because it is a simple text file. (An example of the HOSTS format is provided in the file named HOSTS.sam in the Windows NT %systemroot%\System32\Drivers\Etc directory. This is only an example file; do not use this file as the primary HOSTS file.)Edit the sample HOSTS file (created when you install TCP/IP) to include remote host names and IP addresses for each computer with which you will communicate.

LMHOSTS

The LMHOSTS file is a local text file that maps IP addresses to NetBIOS computer names. It contains entries for Windows-networking computers located outside the local subnet. The LMHOSTS file is read when WINS or broadcast name resolution fails; resolved entries are stored in a local cache for later access.

For example, the LMHOSTS table file entry for a computer with an address of 192.45.36.5 and a computer name of mrp2 looks like this:

192.45.36.5 mrp2

You can create the file by using a text editor — for example, Notepad — to create, and change the LMHOSTS file because it is a simple text file. (An example of the LMHOSTS format is provided in the file named LMHOSTS.sam in the Windows NT %systemroot%\System32\Drivers\Etc directory. This is only an example file; do not use this file as the primary LMHOSTS file.)Edit the sample LMHOSTS file (created when you install TCP/IP) to include remote NetBIOS names and IP addresses for each computer with which you will communicate.

The LMHOSTS file is typically used for small-scale networks that do not have servers. For more information about the LMHOSTS file, see "Using LMHOSTS Files" chapter in this book.