WINS

Revision as of 08:43, 20 August 2008

This is a non-FreeBSD specific term referring to a Microsoft technology for hostname resolution that can be implemented using Samba. It features in this wiki for reference.

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

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

The WINS service on Unixlike OSes is implemented through Samba. WINS is primarily intended for use on networks that contain many SMB (Windows) network hosts, where an ability to resolve their hostnames without resorting to broadcasting will improve network performance and efficiency.

DHCP

The DHCP server is capable of sending details of one or more WINS 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.

When using DHCP to send details of the WINS service servers to Microsoft Windows based hosts it is worth setting option #46, known as the WINS/NBT Node Type (Microsoft) or NetBIOS Node Type (others), to a value of '8'. This value configures the behaviour of the name resolution order on these hosts. The available options are:

• 1 - 'bnode', for broadcast only;
• 2 - 'pnode', for WINS only;
• 4 - 'mnode', for broadcast first, WINS second;
• 8 - 'hnode', for WINS first, broadcast second;

The default behaviour of Microsoft Windows based hosts is to use option '8' when WINS server addresses are specified, either by DHCP or when manually configured on the host, and use option '1' when neither DHCP nor manual configuration specify a WINS server address.

For Microsoft Exchange Administrators

Those using Microsoft Exchange 2000 Server or Exchange Server 2003 in an Active Directory environment may find it worth noting that WINS is required for full functionality due to various dependencies in the Exchange server services. See this knowledge base article for further details.

See Also

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