About Name Resolution Services
SunLink Server WINS with TCP/IP requires a unique IP address and computer name for each computer on the network. Although programs use IP addresses to connect computers, administrators use "friendly" names to connect them. As a result, TCP/IP internetworks require a name resolution service that converts computer names to IP addresses and IP addresses to computer names.
An IP address is the unique address by which all other TCP/IP devices on the internetwork recognize that computer. For TCP/IP and the Internet, the computer name is the globally known system name, plus a Domain Name System (DNS) domain name. (On the local network, the computer name is the name that was supplied either during SunLink Server or Windows NT setup.) To ensure that both names and IP addresses are unique, a computer using NetBIOS over TCP/IP registers its name and IP address on the network during system startup.
NetBIOS and DNS Computer Names
SunLink Server 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 the DNS naming convention. 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 interoperability possible between the two types of components. SunLink Server software combines the NetBIOS computer name with the DNS domain name to form the FQDN.
Note -
In a SunLink Server system, the NetBIOS computer name defaults to the same name as the DNS host name. You can change the default if you need unique names.
A computer can use one or more of the following methods to ensure accurate name resolution in TCP/IP internetworks:
-
Windows Internet Name Service (WINS)
A computer can use WINS if at least one WINS server is available that contains a dynamic database that maps computer names to IP addresses. WINS can be used in conjunction with broadcast name resolution for an internetwork where other name resolution methods are inadequate. As described in the following section, WINS is a NetBIOS over TCP/IP mode of operation.
-
Broadcast name resolution
A computer also can use broadcast name resolution, which is a NetBIOS over TCP/IP mode of operation defined in RFC 1001/1002 as b-node. This method relies on a computer making IP-level broadcasts to register its name by "announcing" it on the network. Each computer in the broadcast area is responsible for challenging attempts to register a duplicate name and for responding to name queries for its registered name.
-
DNS name resolution
The Domain Name System provides a way to look up name mappings when connecting a computer to foreign hosts using NetBIOS over TCP/IP or applications such as FTP. (SunLink Server software does not use this method.)
-
An LMHOSTS file to specify the NetBIOS computer name and IP address mappings, or a HOSTS file to specify the DNS name and IP address.
On a local computer, the HOSTS file (used by Windows Sockets applications to find TCP/IP host names) and LMHOSTS file (used by NetBIOS over TCP/IP to find Microsoft networking computer names) can be used to list known IP addresses mapped with corresponding computer names. LMHOSTS is used for name resolution for small-scale networks or remote subnets where WINS is not available.
NetBIOS over TCP/IP (NetBT) Name Resolution
NetBIOS over TCP/IP (NetBT) is the session-layer network service that performs name-to-IP address mapping for name resolution. In the SunLink Server program, NetBT is implemented through 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 NetBT modes supported by SunLink Server software are:
-
b-node - Uses broadcast messages to resolve names
-
h-node - First uses another type of 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 Windows client computers are b-node and h-node.
For DHCP users, the node type may be assigned by the DHCP server (depending on how the client has been configured). 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 also can use LMHOSTS files for name resolution, depending on how TCP/IP is configured on a particular computer.
SunLink Server software can respond to b-node and h-node NetBT modes.
B-Node (Broadcast Node)
The b-node mode uses broadcasts for name registration and resolution. For example, if CLIENT_PC1 wants to communicate with CLIENT_PC2, it will broadcast to all machines that it is looking for CLIENT_PC2 and then will wait a specified time for CLIENT_PC2 to respond.
The b-node mode has two major problems:
-
In a large environment, it loads the network with broadcasts.
-
Typically, routers do not forward broadcasts, so computers that are on opposite sides of a router will never hear the requests.
H-Node (Hybrid 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 another node type that uses broadcast messages as a last effort. If the WINS server is down--making broadcast messages a necessity--the computer continues to poll the WINS server until it can be reached again. The h-node also can be configured to use the LMHOSTS file after broadcast name resolution fails.
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, allowing computers on the same side of a router to 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 used in SunLink Server networks to allow messages to go across routers. The modified b-node does not use 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.
Windows for Workgroups 3.11 uses 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--but modified b-node is not an ideal solution.
WINS and Broadcast Name Resolution
WINS provides a distributed database for registering and querying dynamic computer name-to-IP address mappings in a routed network environment. WINS solves the problems that occur with name resolution in complex internetworks.
WINS reduces the use of local broadcasts for name resolution and allows users to locate systems easily on remote networks. Additionally, when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets, the changes are updated automatically in the WINS database. Neither the user nor the network administrator needs to make changes manually.
The following sections discuss how name resolution is provided by WINS and name query broadcast messages.
WINS in a Routed Environment
WINS consists of the following two components:
-
The WINS server, which handles name queries and registrations
-
Client software, which queries for computer name resolution
Windows networking clients (WINS-enabled Windows NT, Windows 98, Windows 95, or Windows for Workgroups 3.11 computers) can use WINS directly. Non-WINS computers on the internetwork 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 broadcasts and then respond for names that are not on the local subnet).
To allow browsing without WINS, the network administrator must ensure that the users' primary domain has SunLink Server, Windows NT Server, or Windows NT Workstation computers on both sides of the router to act as master browsers. These computers need correctly configured LMHOSTS files with entries for the domain controllers across the subnet.
With WINS, such strategies are not necessary because the WINS servers and proxies transparently provide the support necessary for browsing across routers where domains span the routers.
Note -
If a client computer running Windows NT also is DHCP-enabled, and if the administrator specifies WINS server information as part of the DHCP options, the computer automatically will be configured with WINS server information.
In a WINS and broadcast name resolution environment, a WINS-enabled client computer will behave in a different manner than a non-WINS-enabled client computer. These differences will be apparent in the way these clients handle resolution, registration, release, and renewal, described in the next sections.
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. Regardless of which name resolution method is used, the process is not visible 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 another device.
-
If WINS is enabled on the client - The computer first queries the WINS server. If this fails, it sends name registration and query requests (as broadcast messages) in the following series of steps:
-
A client's name query request is sent first to the WINS server. If the name is found in the WINS database, then the client can establish a session based on the address mapping received from the WINS server.
-
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.
-
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 User Datagram Protocol (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 that it currently is a 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, as follows:
-
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 time stamp, 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, 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 immediately can give that name to the requesting client because it knows that the old client no longer is 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.
Note -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 name queries that originate on their local subnet.
Name Renewal
Client computers periodically 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, as follows:
-
Default renewal interval for entries in the WINS database is six days.
-
WINS clients register and refresh every three days.
-
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.
WINS Proxy
A WINS proxy is a WINS-enabled computer that helps resolve name queries for non-WINS enabled computers in routed TCP/IP intranets. By default, non-WINS enabled computers are configured as b-node, which uses IP broadcasts for name queries. The WINS proxy computer listens on the local subnet for IP broadcast name queries.
When a non-WINS enabled computer sends an IP name query broadcast, the WINS proxy accepts the broadcast and checks its cache for the appropriate NetBIOS computer name-to-IP-address mapping. If the WINS proxy has the correct mapping in its cache, the WINS proxy sends this information to the non-WINS computer. If the name-to-IP-address mapping is not in cache, the WINS proxy queries a WINS server for the name-to-IP-address mapping.
If a WINS server is not available on the local subnet, the WINS proxy can query a WINS server across a router. The WINS proxy caches (stores in memory) computer name-to-IP-address mappings it receives from the WINS server. These mappings are used to respond to subsequent IP broadcast name queries from b-node computers on the local subnet.
The name-to-IP-address mappings that the WINS proxy receives from the WINS server are stored in the WINS proxy cache for a limited time. (By installation default, this value is six minutes. The minimum value is one minute.)
When the WINS proxy receives a response from the WINS server, it stores the mapping in its cache and responds to any subsequent name query broadcasts with the mapping received from the WINS server.
The role of the WINS proxy is similar to that of the DHCP/BOOTP relay agent, which forwards DHCP client requests across routers. Because the WINS server does not respond to broadcasts, a computer configured as a WINS proxy should be installed on subnets that include computers that use broadcasts for name resolution.
Note -
To configure a Windows NT, Version 4.0, computer as a WINS proxy, you must manually edit that computer's registry. The EnableProxy keyword must be set to 1 (REG_DWORD). This keyword is located in the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters
WINS and Dial-Up TCP/IP Networking Clients
Dial-up TCP/IP networking clients provide remote networking for telecommuters, mobile workers, and system administrators who monitor and manage servers at multiple branch offices. Users of dial-up TCP/IP networking on Windows 98, Windows 95, or Windows NT computers can dial in to access their networks remotely for services such as file and printer sharing, electronic mail, scheduling, and database access.
Windows 98, Windows 95, and Windows NT support routing TCP/IP traffic over dial-up TCP/IP connections through several different types of dial-up TCP/IP networking servers, including the following:
-
UNIX system servers that support either of the industry-standard point-to-point protocol (PPP) or serial line IP (SLIP) dial-up TCP/IP networking standards
-
Windows NT remote access service (RAS) servers
-
Third-party remote access service servers that support PPP and/or SLIP connections, such as those that are available from CISCO, 3COM, and Bay Networks
Dial-up Windows 98, Windows 95, and Windows NT computers that are configured to route TCP/IP also can be configured to use WINS servers. (For details, see your Microsoft documentation.)
Dial-up Windows 98, Windows 95, and Windows NT computers that are configured to route TCP/IP and use WINS can access remotely their networks for services, including SunLink Server and Windows NT file and print sharing, electronic mail, scheduling, and database access.
- © 2010, Oracle Corporation and/or its affiliates