Name Resolution

NetBIOS over TCP/IP is probably the most common implementation and is often used in preference to NetBIOS "on the wire" (NetBIOS Frames Protocol otherwise known as NetBEUI or just NetBIOS) or in preference to NetBIOS over IPX/SPX. NetBIOS over TCP/IP is also probably most often used to carry the SMB / CIFS protocol.

When implementing NetBIOS over TCP/IP, Name resolution i.e. the mechanisms for converting NetBIOS names to IP addresses is critically important. This topic is sufficiently important (and so often the source of many problems) to merit special discussion.

It is important to note that Name resolution is separate from the Browser service. Name resolution is specific to NetBIOS over TCP/IP; the Browser service runs over SMB which runs over NetBIOS Frames Protocol, NetBIOS over IPX or NetBIOS over TCP/IP. The mapping of NetBIOS names to IP addresses is distinct from the service that makes lists of systems available (for example in "Network Neighborhood" or "My Network Places") which is provided by the Browser service. Of course services such as the Browser service (that runs over SMB) are unlikely to function correctly if the underlying facilities such as Name resolution are not working properly.

The Name resolution mechanisms discussed here do not necessarily conflict with the mechanisms discussed in the standards RFC 1001 and RFC 1002, but can be seen as alternative implementations with various enhancements.

In practice it seems that the main implementations of NetBIOS over TCP/IP utilize a local cache for Name resolution; name to IP address mappings that have recently been resolved are held in a local cache for a short time which can reduce the need to access the network to resolve names to IP addresses.


Many implementations of NetBIOS over TCP/IP make use of an LMHOSTS file. The LMHOSTS file is similar to the traditional hosts file; both are simple text files listing IPv4 addresses and host names. The LMHOSTS file consists of several lines each of which may have an IPv4 address followed by white space, a NetBIOS name and possibly additional parameters or comments. Most implementations support the use of the hash # character to indicate comments or additional parameters. While the basic structure described above is fairly universal, the use of additional information is implementation dependent.

In the SAMBA implementation, a NetBIOS hostname can be followed by a hash # and then two hexadecimal digits specifying the NetBIOS name type. In the Microsoft implementation, special characters can be included by enclosing the name in quotes and entering the hexadecimal code as \0xnn or \nn; the sixteenth byte can be specified in this manner but the name must be padded with spaces to ensure it is sixteen bytes long. In the Microsoft implementation several "directives" can be included in the file, beginning with the hash # character.

Microsoft has produced articles describing their use of LMHOSTS files including:

Article ID: Q101927

"The Lmhosts File for TCP/IP in Windows"

Article ID: Q102725

"LMHOSTS File Information and Predefined Keywords"

Article ID: Q104576

"Embedding Non-printable Characters in LMHOSTS Computer Names"

Article ID: Q108295

"TCP/IP Name Resolution"

Article ID: Q150800

"Domain Browsing with TCP/IP and LMHOSTS Files"

Article ID: Q180094

"How to Write an LMHOSTS File for Domain Validation and Other Name Resolution Issues"


The NetBIOS Name Service is implemented in SAMBA as nmbd. This service can also support the browsing service (which is a separate service). The nmbd service can also be used as a WINS server or WINS proxy.

Microsoft has produced an implementation of the NetBIOS Name Service (NBNS) called Windows Internet Name Service (WINS). The use of WINS is described in the Microsoft article:

Article ID: Q119493

"NetBIOS over TCP/IP Name Resolution and WINS"

Hosts and DNS

Within Microsoft networks, NetBIOS Name resolution can also make use of the traditional hosts file and the Domain Name System (DNS). For this mechanism to work NetBIOS names need to be the same as the unqualified TPC/IP host name. The implication of this is that the NetBIOS names will also conform to the constraints of the DNS name space (i.e. names can only consist of letters, digits and the dash / hyphen character - and can not contain other special characters otherwise allowed in NetBIOS names such as the underscore character _ ). Microsoft describe the use of a hosts file and the DNS in the article:

Article ID: Q142309

"NetBIOS Name Resolution Using DNS and the HOSTS File"

Client Resolution

Systems can use a combination of the above services to resolve NetBIOS names to IP addresses for example sequentially searching cache, lmhosts file, nbns service, hosts files and the DNS.

Name management

The management of names can be a complex issue. To avoid problems it is important that multiple systems do not attempt to update the same name registration service.

In Microsoft NT 4.0 networks a typical arrangement will be as follows:

  1. A DHCP server will allocate IP addresses to client systems when they boot.

  2. Client systems are allocated NetBIOS names at installation time. The names conforms to the DNS rules for names and are the same as the unqualified DNS name. At boot time the client registers it's NetBIOS name and DHCP assigned address with a NBNS server (often a WINS server).

  3. The Microsoft DNS server is configured to resolve host names by taking the unqualified DNS name and passing the enquiry to the WINS server.

Other implementations make use of Dynamic DNS (DDNS) with either a DHCP server or the clients themselves updating the DNS server. In this arrangement provided the NetBIOS names conform to the DNS rules for names and are the same as the unqualified DNS name, the need for a NBNS server (WINS) can be removed.