WINS

WINS, or Windows Internet Name Server, is a network based service created (somewhat unsurprisingly, given the name) by Microsoft and is their implementation of the NBNS, or NetBIOS Name Server, service.

The WINS service shares similarities to the ubiquitous DNS in that it is a form of hostname-to-IP resolution. It is only capable of resolving NetBIOS based hostnames like LABPC012 and not FQDN based internet hostnames like www.freebsdwiki.net.

Origins

Early network implementations that had their origins in mainframes and as such network hosts were few in number. This permitted the use of hostname resolution through localhost text-based files to be used since changes were few and far between.

With the advent of newer technology it soon became possible to buy cheap personal computers to replace large expensive mainframe systems. Maintaining localhost files became impossible with the vast number of hosts on the network which meant hosts had to resort to broadcasting queries to the network in order find other hosts. These broadcasts resulted in saturating the network and every host had to take note of a query to determine whether it had to reply or not, thereby causing computers to run slowly.

It soon became apparent that a service was required that would reduce the network load while making hostname resolution more efficient and quicker. This is where NBNS, and later WINS, came into existence.

Features

The WINS service works within a network subnet and provides name resolution based on host NetBIOS names and their associated IP address. It can be thought of as a kind of Dynamic-DNS style service but instead of internet-based hosts it deals with workgroup-based and domain-based hosts. As such it is tied into the LAN-Manager style network infrastructure, nowadays more commonly referred to as SMB (latterly CIFS) on Microsoft platforms or Samba on UNIX and Unix-like platforms. The server operating as the primary WINS service is often referred to as the local master browser in a workgroup or domain master browser in an NT-based domain. It is possible to have multiple WINS service servers on the same network subnet with one being the master browser and the others being backup browser servers.

The service differs from DNS in that it cannot span across networks via routers on IP based networks, therefore it is limited to the network subnet it resides within. To work around this limitation a push/pull replication setup can be implemented and often utilised in a spoke/hub topological configuration. Without this arrangement a host on the network subnet can only query the local WINS service and not know about hosts on other subnets. However with this arrangement a host can determine another host's IP address from another network subnet and then rely on TCP/IP routing to communicate to it which makes it more akin to DNS.

With DNS it is possible to have the same hostname several times but under different sub-domains. A typical example would be www.us.domain.net and www.uk.domain.net where the hostname www exists twice with one under the us and the other under the uk sub-domains. This is possible because DNS is hierarchical in operation. With WINS there is no hierarchical system and as such duplicate hostnames cannot exist, especially across different network subnets, when the push/pull system is used. This is not necessarily a limitation of WINS since a flat domain model would not permit more then one hostname to be used, and WINS is intended to be used on corporate networks as part of file and print sharing where server names are unique.

The WINS service has a function that does not exist in DNS: the ability to have a host on the network assume the role of a WINS service should the official WINS service become unavailable (for example, if it had crashed). This system is known as having an 'election' where each host broadcasts its credentials to the network and the "highest" level system is granted the rights to become the local browser master. The levels are determined on a weighted system as follows:

• Primary Domain Controller (PDC, used of NT based networks);
• Windows NT, Windows 2000, Windows XP or Windows Server NT, 2000 (non-PDC systems);
• Windows 95 or Windows 98;
• Windows for Workgroups 3.11;

Related Systems

The WINS service is very functional on its own but it does rely on other network services with which to make it effective. The following are based on making the WINS service available using FreeBSD as the host operating system:

Samba

While the WINS service is implemented through Samba and therefore an obvious prerequisite WINS is primarily intended for use on networks that contain file and print servers where resolving their hostnames without resorting to broadcasting thereby improve network performance and efficiency.

DHCP

The DHCP server is capable of sending details of one or more WINS service servers as part of an IP address request or renewal just as it would with default gateway and DNS details. The DHCP configuration option #44, called 'WINS/NBNS' on Microsoft platforms or 'NetBIOS Name Service' on other DHCP implementations, holds the IP addresses for the WINS service hosts.

The other side of WINS is that it tracks hostnames to the IP addresses of hosts on the network that have themselves been given a dynamically allocated IP address from DHCP.

Notes

The Microsoft implementation of the WINS service required a Primary Domain Controller, and therefore a full NT-domain to exist, in order to have a domain master browser and, from there, be able to span multiple network subnets using the push/pull replication setup. The Samba implementation does not have this requirement and can function this way even in workgroup mode however a Samba WINS server cannot replicate with a Microsoft WINS server and vice-versa. Therefore it is important to only use one implementation across all network subnets in order to avoid inconsistencies between WINS service servers.

See Also

The Samba documentation project has a good description of the WINS service.