Chapter 32 - Networking Name Resolution and Registration
Administration of Microsoft TCP/IP and related services splits roughly into two functional areas:
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.
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:
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.
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: http://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.
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 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.
For example, when the IP address is 18.104.22.168 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.
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:
The search for a match of the destination address in the route table proceeds from the specific to the general in the following order:
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.
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:
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
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
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:
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
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.
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:
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:
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:
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.
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.
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 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:
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.
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.
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 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.
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.
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:
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.
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.
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.
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 22.214.171.124 and a host name of mfg1.widgets.com looks like this:
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.
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 126.96.36.199 and a computer name of mrp2 looks like this:
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.