WINS provides a distributed database for registering and querying dynamic computer name-to-IP address mappings in a routed network environment. If you are administering a routed network, WINS is your best first choice for name resolution, because it is designed to solve the problems that occur with name resolution in complex internetworks.
WINS reduces the use of local broadcasts 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 network administrator needs to make manual accommodations for name resolution in such a case.
The WINS protocol is based on and is compatible with the protocols defined for NBNS in RFCs 1001/1002, so it is interoperable with any other implementations of these RFCs.
This section provides an overview of how WINS and name query broadcasts provide name resolution on Windows networks. For information about setting up WINS servers, see Chapter 14, "Installing and Configuring WINS Servers."
WINS consists of two components: the WINS server, which handles name queries and registrations, and the client software, which queries for computer name resolution.
Windows-based networking clients (WINS-enabled Windows NT 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, which are WINS-enabled computers that listen to name query broadcasts and then respond for names that are not on the local subnet or are p-node computers.
On a Windows NT network, users can browse transparently across routers. To allow browsing without WINS, the network administrator must ensure that the users' primary domain has 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.
The following figure 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 broadcasts access the WINS server through proxies. Proxies only pass name query packets and verify that registrations do not duplicate existing systems in the WINS database. Proxies, however, do not register b-node systems in the WINS database.
Figure 12.5 Example of an Internetwork with WINS Servers
The proxy communicates with the WINS server to resolve names (rather than maintaining its own database) and then caches the names for a certain time. The proxy serves as an intermediary, by either communicating with the WINS server or supplying a name-to-IP address mapping from its cache. The following illustration shows the relationships among WINS servers and clients, including proxies for non-WINS computers and the replication between WINS servers.
Figure 12.6 Example of Clients and Servers Using WINS
In the above figure, ClientA can resolve names by first querying the WINS server and, if that fails, then using broadcast name queries. ClientB, which is not WINS-enabled, can only resolve names using broadcast name queries, but when ClientC receives the broadcast, it forwards the request to the WINS server and returns the address to ClientB.
However, a complex environment presents additional problems. For example, an internetwork might consist of two subnets, with all the computers belonging to DomainA attached to Subnet1, all the computers in DomainB attached to Subnet2, and computers from DomainC attached to either of the subnets. In this case, without WINS, DomainA computers can browse Subnet1, DomainB computers can browse Subnet2, and DomainC computers can browse both subnets as long as the primary domain controller for DomainC is available. With WINS, computers from all domains can browse all subnets if their WINS servers share databases.
If the Windows NT client computer is also DHCP-enabled and the administrator specifies WINS server information as part of the DHCP options, the computer usually will be automatically configured with WINS server information. You can manually configure WINS settings, as described in Chapter 11, "Installing and Configuring Microsoft TCP/IP and SNMP":
With WINS servers in place on the internetwork, names are resolved using two basic methods, depending on whether WINS resolution is available and enabled on the particular computer. Whatever name resolution method is used, the process is transparent to the user after the system is configured.
If WINS is not enabled The computer registers its name by broadcasting name registration request packets to the local subnet via UDP datagrams. To find a particular computer, the non-WINS computer broadcasts name query request packets on the local subnet, although this broadcast 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 The computer first queries the WINS server, and if that does not succeed, it broadcasts its name registration and query requests via UDP datagrams (h-node), in the following series of steps:
Figure 12.7 Name Registration in the WINS Database
Figure 12.8 Processing a Name Query Request
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 ensures that the computer's name and IP address are unique for each device.
If WINS is enabled 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 For a non-WINS computer to register its name, a name registration request packet is broadcast to the local network, stating its 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. If the registration request is not contested within a specific time period, the computer adopts that name and address.
Once a non-WINS computer has claimed a name, it must challenge duplicate name registration attempts and respond positively to name queries issued on its registered name by sending a positive name query response. This response contains the IP address of the computer so that the two systems can establish a session.
When a computer finishes with a particular name (such as when the 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 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, and the version number is updated so that the database changes will be propagated among the WINS servers. Extinct entries remain in the database for a designated period of time to enable the change to be propagated to all WINS servers.
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 that computer released its name during an orderly shutdown, the WINS server does not challenge the name. If the computer restarts because of a system reset, the name registration with a new address causes the WINS server to challenge the registration, but the challenge fails and the registration will succeed, because the computer no longer has the old address.
If WINS is not enabled 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, the computer simply ignores the request, allowing other computers on the network to acquire the name that it has released.
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 only respond to name queries that originate on their local subnet.
A renewal is a timed reregistration of a computer's name with the WINS server. The timestamp for an entry indicates the entry's expiration date and time. If the entry is owned by the local WINS server, the name is released at the time specified unless the client has reregistered. An entry defined as static never expires. If the entry is owned by another WINS server, the entry is revalidated at the time specified. If it does not exist in the database of the WINS server that owns the entry, it is removed from the local WINS database. A request for name renewal is treated the same as a new name registration.
Renewal provides registration reliability through periodic reregistering of names with the WINS servers. The default renewal interval for entries in the WINS database is four days. WINS clients register and refresh every two days. Because this setting reduces network traffic and allows WINS to serve many more nodes than before, you should not lower it. The primary and backup WINS servers should have the same renewal interval.