Chapter 3 - Implementation Considerations

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.

Client Configuration Options

This section begins with a high-level overview of IP addressing, introduces the Dynamic Host Configuration Protocol (DHCP), and concludes with a brief overview of IP-addressing under Windows NT Remote Access Service (RAS). For further information about RAS, see the RAS chapters in this manual.

Understanding IP Addressing

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

Note Users running Windows NT on networks with DHCP servers can take advantage of automatic system configuration and do not need to manually configure 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 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 3.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 3.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

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 3-1.

 

Figure 3-1 Internetwork Routing Through Routers 

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.

Dynamic Host Configuration Protocol

Assignment and maintenance of IP-address information can be an administrative burden. To provide a degree of relief, the Dynamic Host Configuration Protocol (DHCP) offers dynamic configuration of IP addresses and related information.

The network administrator controls how IP addresses are assigned by specifying lease durations that specify how long a computer can use an assigned IP address before having to renew the lease with the DHCP server. DHCP provides safe, reliable, and simple TCP/IP network configuration, prevents address conflicts, and helps conserve the use of IP addresses through centralized management of address allocation.

For example, the IP address is released automatically for a DHCP client computer that is removed from a subnet, and a new address for the new subnet is automatically assigned when that computer reconnects on another subnet. Neither the user nor the network administrator needs to supply new configuration information. This feature is significant for both mobile computer users with portables that are docked at different computers and for computers that are frequently moved.

The DHCP client and server services for Windows NT are implemented under the following RFCs: 1533, 1534, 1541, 1542.

Figure 3-2 illustrates a DHCP server providing configuration information on two subnets. If, for example, Client C is moved to Subnet 1, the DHCP server automatically supplies new TCP/IP configuration information the next time that Client C is started.

 

Figure 3-2 DHCP Clients and Servers on a Routed Network 

Note You can configure Windows NT Server 4.0 to act as a DHCP relay agent. (A DHCP relay agent relays DHCP and BOOTP broadcast messages between a DHCP/BOOTP server and a client across an IP router.) If it is impractical or impossible to configure the router in the illustration to support DHCP relay, a Windows NT Server computer on Subnet 2 can be configured as the DHCP relay agent to forward DHCP messages to Subnet 1. You could also replace the router in the illustration with a Windows NT Server 4.0 computer that is enabled as a DHCP relay agent and configured to run the multiprotocol routing service. For more information about the multiprotocol routing service, see the Multiprotocol Routing chapters in this manual. For information about configuring either DHCP relay or multiprotocol routing, see Windows NT Help.

How DHCP Clients Get IP Addresses

DHCP uses a client-server model and is based on leases for IP addresses. As illustrated in Figure 3-3, a DHCP client passes through four phases as it acquires a lease from the DHCP server.

 

Figure 3-3 DHCP Client and Server Interaction During System Startup 

During system startup, a DHCP client computer sends an IP Lease Request (as a broadcast message) on the network. Each DHCP server that receives the client's request responds with an IP Lease Offer containing an IP address and valid configuration information for the client that sent the request.

After sending the IP Lease Request, the client waits for IP Lease Offers to come back. If the client does not receive an IP Lease Offer from a DHCP server, it will resend the IP Lease Request four times every five minutes until it does.

The client then selects one of the IP Lease Offers—typically the first one received—and responds to the DHCP server with an IP Lease Selection, which indicates acceptance of the offered IP Address.

The selected DHCP server sends an IP Lease Acknowledgment that contains the address first sent in the IP Lease Offer, plus a valid lease for the address and the TCP/IP network configuration parameters for the client. After the client receives the acknowledgment, it can participate on the TCP/IP network and complete its system startup.

Note When a DHCP client is shut down and restarted (on the same subnet), it will typically obtain a lease for the same IP address it had prior to the shutdown.

As the lease approaches its expiration date, the client tries to renew it:

• When 50% of the lease time has expired, the client tries to renew the lease with the DHCP server that originally assigned it. 

• If the client is unable to communicate with the original DHCP server, and 87.5% of the lease time has expired, the client tries to renew the lease by broadcasting a request to any available DHCP server. 

• If the lease expires, the client must immediately discontinue using the IP address and begin again with a new IP Lease Request.

In Windows NT Server, the network administrator uses DHCP Manager to define local policies for address allocation, leases, and other options. For information about the steps for setting up TCP/IP using DHCP, or for information about the DHCP Manager tool, see Windows NT Help. For further information about planning for DHCP deployment, see the Microsoft Windows NT Resource Kit Networking Guide.

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 3-4, 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 3-4 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. (Of course, the network administrator must also reserve that range of static addresses on the DHCP server, if present, to make sure that those addresses are not assigned to other computers on the network.)

Clients running RAS can use the same name resolution services as hosts connected directly to the internetwork. For further information about RAS, see the RAS chapters in this manual.

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 Windows Internet Name Service (WINS) and broadcast name resolution. 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

Note The RFCs refer to a NetBIOS Name Server (NBNS). WINS is an enhanced NBNS.

The two most common node types for client computers running Windows NT are h-node and b-node. If the client computer is configured to use WINS, Windows NT defaults to h-node; otherwise, the default node type is b-node.

Important For DHCP clients on a Windows NT network, the node type is assigned by the DHCP server.

When WINS servers are in place on the network, NetBT resolves names on a client computer by communicating with the WINS server. When WINS servers are not in place, 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 In Windows NT, the NETBT.SYS module provides the NetBT functionality that supports name registration and resolution modes.

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 (typically through DHCP) 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.

Note For Microsoft TCP/IP users who configure TCP/IP manually, h-node is used by default, unless the user does not specify addresses for WINS servers when configuring TCP/IP.

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 Microsoft Windows NT Resource Kit Networking Guide), 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 also be configured as WINS proxy agents to help the transition to using WINS. For more details, see the next section.

Windows Internet Name Service (WINS) and Broadcast Name Resolution

WINS provides a replicated, dynamic database for registering and querying NetBIOS computer-name-to-IP address mappings in a routed network environment. WINS is designed to solve the problems that occur with name resolution in complex internetworks.

WINS reduces the use of local broadcast messages for name resolution and allows users to easily locate systems on remote networks. Furthermore, when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets, the changes are automatically updated in the WINS database: Neither the user nor the administrator needs to make changes manually.

Note The WINS protocol is based on and is compatible with the protocols defined for NBNS in RFCs 1001 and 1002, so it is interoperable with any other implementations of these RFCs.

This section provides an overview of how name resolution is provided by WINS and name-query broadcast messages. For information about installing and configuring WINS servers, see Windows NT Help.

WINS in a Routed Environment

WINS consists of two components:

• The WINS server, which handles name queries and registrations 

• The client software, which queries for computer name resolution

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 (WINS-enabled computers that listen to name-query broadcast messages and then respond for names that are not on the local subnet or are p-node computers).

On a Windows NT network, users can view resources transparently across routers. To allow this browsing without WINS, the administrator must ensure that the users' primary Windows NT domain has computers running either Windows NT Server or Windows NT Workstation on both sides of the router to act as master browsers. These computers need correctly configured LMHOSTS files with entries for the Windows NT domain controllers across the subnet.

With WINS such strategies are not necessary because the WINS servers and proxies provide the support necessary for browsing across routers where Windows NT domains span the routers.

Figure 3-5 shows a small internetwork with three local area networks connected by a router. Two of the subnets include WINS name servers, which can be used by clients on both subnets. WINS-enabled computers, including proxies, access the WINS server directly, and the computers using broadcast messages access the WINS server through proxies. Proxies intercept the broadcast messages and send them directly to the WINS server.

 

Figure 3-5 Example of an Internetwork with WINS Servers 

The proxy communicates with the WINS server to resolve names and then caches the names for a certain time. The proxy serves as an intermediary, either communicating with the WINS server or supplying a name-to-IP address mapping from its cache. Figure 3-6 shows the relationships among WINS servers and clients, including proxies for non-WINS computers.

 

Figure 3-6 Example of Clients and Servers Using WINS 

In Figure 3-6, Client A is a not enabled for WINS, Client B is enabled for WINS, and Client C is a WINS proxy agent. Table 3.3 shows the typical steps that Client A and Client B take when resolving names.

Client A (Non-WINS)	Client B (WINS)
Client A sends a query (as a broadcast message) for Client X's IP address. Client X (not shown) is not on the local subnet. 1	Client B queries the WINS server for Client A's IP address.
Client C (WINS proxy) intercepts the broadcast message and sends it directly to the WINS server. 2	The WINS server responds directly to Client B with Client A's IP address. 3
The WINS server responds directly to Client C with Client X's IP address.	If the WINS server is unreachable, the query fails. Client B switches to b-node and sends the query as a broadcast message on the local subnet.
Client C responds directly to Client A with Client X's IP address.	Client A receives the broadcast and responds directly to Client B.

1 If Client X was on the local subnet, it would respond directly to Client A's query. 

2 Client C may already have the requested information in cache. If so, Client C responds directly to Client A without going to the WINS server. 

3 Both examples assume that the requested information is available in the WINS database on the server. 

Note If the client computer running Windows NT is also DHCP-enabled, and if the administrator specifies WINS server information as part of the DHCP options, the computer will usually be automatically configured with WINS server information. You can manually configure WINS settings, as described in Windows NT Help.

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

With WINS servers in place on the internetwork, 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) in the following series of steps:

1. During TCP/IP configuration, the client computer registers its name with the WINS server. This is shown in Figure 3-7. (Notice that the WINS database is replicated among all WINS servers on the internetwork.) 

    

   Figure 3 - 7 Name Registration in the WINS Database 

2. As illustrated in Figure 3-8, a client's name query request is sent first to the WINS server. If the name is found in the WINS database, the client can establish a session based on the address mapping received from the WINS server. 

    

   Figure 3 - 8 Processing a Name Query Request 

3. If the WINS server query is unsuccessful, and if the client computer is configured as an h-node, the client computer sends name query request packets (as broadcast messages) in the same manner as a non-WINS-enabled computer. 

4. Finally, if other methods fail, the local LMHOSTS file is checked. (Included in the search are any centralized LMHOSTS files referred to in #INCLUDE statements in the local file.)

WINS servers accept and respond to UDP name queries. Any name-to-IP address mapping registered with a WINS server can be provided reliably as a response to a name query. However, a mapping in the database does not ensure that the related device is currently running, only that a computer claimed the particular IP address and it is a currently valid mapping.

Name Registration

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

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.

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.

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 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.

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.

Name Renewal

Periodically, client computers are required to renew their NetBIOS name registrations with the WINS server. When a client computer first registers with a WINS server, the WINS server returns a message that indicates when the client will need to renew its registration:

• The default renewal interval for entries in the WINS database is four days. 

• WINS clients register and refresh every two days. 

• The primary and backup WINS servers should have the same renewal interval. 

• An entry defined as static never expires.

If the entry is owned by the local WINS server, the name is released at the specified time unless the client has renewed it. If the entry is owned by another WINS server, the entry is revalidated at the specified time. If the entry does not exist in the database of the WINS server that owns the entry, it is removed from the local WINS database. A name renewal request is treated as a new name registration.

Caution Incorrectly adjusting the renewal interval might adversely affect system and network performance.

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 3-9 illustrates the parent-child relationships of DNS domains.

 

Figure 3-9 A Portion of the DNS Database 

Note As shown in Figure 3-9, 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 3.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 3-10 illustrates the relationship between DNS domains and zones.

 

Figure 3-10 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 Servers and Resolvers

DNS uses a client-server model, where the DNS servers (name servers) contain information about a portion of the DNS database (zone) and make this information available to clients (resolvers). A resolver queries a name server for information about the DNS name space. This name server can, in turn, query other name servers as it tries to respond to the query from the resolver.

A DNS zone administrator sets up one or more name servers for the zone:

• A primary master name server. A primary server contains the master copy of the database files with resource records for all subdomains and hosts in the zone. 

• A secondary master name server. A secondary server receives a replicated copy of the database files from the primary server. When the zone structure changes, the primary master database files are modified and copied to the secondary masters. The secondary master files are never touched. 

• A caching-only name server. Unlike a primary or secondary server, a caching-only server is not associated with any specific DNS zone(s) and contains no database files. A caching-only server starts with no knowledge of the DNS domain structure and must rely on other name servers for this information. Each time a caching-only server queries a name server and receives an answer, it stores the information in its cache. When additional queries come in for this information, the caching-only server answers them directly from cache. Over time, the cache will grow to include the information most often requested.

Although they are not required by the DNS software, secondary servers are a good idea for the following reasons:

• Load balance. Secondary servers ease the load on the primary server. This can be significant in a busy network where name server queries can reach volumes of 20,000 per hour and beyond. 

• Fault tolerance. Secondary servers allow DNS name resolution to continue when the primary server is unavailable. 

• Reduced network traffic. Secondary servers placed in close proximity to client computers reduces internetwork traffic across routers.

Windows NT Server 4.0 includes RFC-compliant, DNS name-server functionality. Windows NT Server, Windows NT Workstation, Windows 95, and Windows for Workgroups 3.11 with Microsoft TCP/IP-32 installed all include DNS-resolver functionality. For more information about configuring TCP/IP to use DNS services, see Windows NT Help.

In addition to the DNS name server service, Windows NT Server 4.0 includes an RPC-based, graphical administration tool, DNS Manager, that enables administrators to remotely administer DNS name servers. The DNS Manager is similar in function to the Windows NT Server 4.0 WINS Manager. For more information about installing or using these tools, see Windows NT Help.

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 an FQDN to find its specific address. As illustrated in Figure 3-11, 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 3-11 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.

DNS and WINS Integration

The structure of a DNS zone changes whenever a new host is added or when an existing host is moved to a different subnet. Because DNS is not dynamic, someone must manually change the DNS database files if the zone is to reflect the new configuration. This results in increased administrative overhead, especially on zones that change frequently.

WINS, on the other hand, was created to ease this type of administrative burden. Coupling DNS with WINS capitalizes on the strengths of each to provide a form of Dynamic DNS. This coupling is supported by the DNS service that runs under Windows NT Server 4.0. With it, you can direct DNS to query WINS for name resolution of the lower levels of the DNS tree in your zones. All of this is transparent to the DNS resolvers, which perceive the DNS name server as handling the entire process. Figure 3-12 illustrates how name resolution works when WINS is integrated with DNS.

 

Figure 3-12 DNS Name Resolution Integrated with WINS 

Suppose a user at a client workstation issues the following command:

net use \\mfg.widgets.universal.com.\public

This command establishes a connection between the client workstation and the public folder on the mfg.widgets.universal.com. server. However, before this connection can be established, the FQDN mfg.widgets.universal.com. must be resolved by DNS—and, in this case, WINS—into an IP address. The process, assuming no cached data on the name servers, is as follows:

1. The DNS resolver on the client sends a recursive request to the local DNS name server to resolve the FQDN. 

2. The local DNS name server sends an iterative request to one of the DNS root servers requesting resolution of the FQDN. The DNS root servers are authoritative for the top-level DNS domains, such as com. 

3. The DNS root server returns a referral to the name servers that are authoritative for the universal DNS domain. 

4. The local DNS name server sends an iterative request to one of the universal name servers. 

5. The universal name server responds with a referral to the widgets name servers. 

6. The local DNS name server sends an iterative request to one of the widgets name servers. 

7. The widgets name servers are running the DNS server on Windows NT Server and are configured to use WINS to resolve the leftmost portion (host name) of the FQDN. When the widgets name server receives the request from the local name server, it passes the mfg piece of the DNS name to its local WINS server for resolution. WINS returns the IP address for mfg to the widgets name server. 

8. The widgets name server returns the IP address for the FQDN to the local DNS name server. The local DNS name server has no knowledge that WINS was involved in the name resolution process. 

9. The local DNS name server completes the recursive request by sending the IP address back to the client resolver. Likewise, the client resolver is completely unaware of the WINS involvement in the process. 

10. The client workstation establishes the session with mfg.widgets.universal.com and connects to the public folder.

Note DNS caching significantly reduces the number of iterative requests processed by name servers throughout the DNS name space.

In this example, only the widgets name server had knowledge of WINS. To the client resolver and all other name servers, it appeared that DNS was responsible for the entire nameresolution process. Furthermore, if the IP address changes for mfg.widgets.universal.com., WINS will automatically handle it. Nothing needs to change with DNS.

For more information about integrating WINS with DNS, see the Microsoft Windows NT Resource Kit Networking Guide. For information about installing and configuring DNS and WINS Servers, see Windows NT Help.

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

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

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 Windows NT Help and the Microsoft Windows NT Resource Kit Networking Guide.