8.1. Name Resolution
TCP/IP networks identify systems by IP addresses, and use a name resolution scheme to associate these addresses with more human-readable text names. In Microsoft's earliest networking implementations (for MS-DOS and Windows for Workgroups), the translation of names to network addresses was carried out in a manner similar to the Address Resolution Protocol (ARP) used on Ethernet networks today. When a system on the network needed an IP address corresponding to a name, it broadcasted the name to every other system on the network and waited for the system that owned the name to respond with its IP address.
The main problem with performing name resolution using broadcast packets is poor performance of the network as a whole, including CPU time consumed by each host on the network, which has to accept every broadcast packet and decide whether to respond to it. Also, broadcast packets usually aren't forwarded by routers, limiting name resolution to the local subnet. Microsoft's solution was to add Windows Internet Name Service (WINS) support to Windows NT, so that the computers on the network could perform a direct query of the WINS server instead of using broadcast packets.
Modern Windows clients use a variety of methods for translating hostnames into IP addresses. The exact method varies depending on the version of Windows the client is running and how the client is configured (i.e., whether a DNS server and/or WINS server is provided). In general, Windows uses some combination of the following methods:
The first method is self-explanatory. A hostname is checked against a cache of hostnames that have been recently resolved to IP addresses. This check helps to save time and network bandwidth for resolving names that are used frequently.
It is possible, although uncommon, for a Windows system to consult a local hosts file, as described in Chapter 3. DNS servers are very common in modern networks. When a Windows system is configured with the IP address of at least one DNS server, it can use DNS to resolve fully qualified domain names, such as those for sites on the Internet. The DNS servers can be either Windows or Unix systems. You can learn more about DNS and DNS server configuration in the book DNS and BIND, by Paul Albitz and Cricket Liu (O'Reilly).
8.1.1. WINS Clients and Server Interaction
There are two types of interaction between a WINS client and a server: the client keeps its own NetBIOS name (or names) registered with the server and queries the server to get the IP address corresponding to the NetBIOS name of another system.
When a WINS client joins the network, it registers its NetBIOS name with the WINS server, which stores it along with the client's IP address in the WINS database. This entry is marked active. The client is then expected to refresh the registration of its name periodically (typically, every four days) to inform the server that it is still using the name. This period is called the time to live, or TTL. When the client leaves the network by being shut down gracefully, it informs the server, and the server marks the client's entry in its database as released.
When a client leaves the network without telling the WINS server to release its name, the server waits until after it fails to receive the expected registration renewal from the client and then marks the entry as released.
In either case, the released name is available for use by other clients joining the network. It might persist in the released state in the WINS database, and if it is not reregistered, the entry is eventually deleted.
More information on WINS can be found in the Microsoft white paper "Windows Internet Naming Service (WINS) Architecture and Capacity Planning," which can be downloaded from the Microsoft web site (http://www.microsoft.com).
8.1.2. Setting Up Samba As a WINS Server
You can set up Samba as a WINS server by enabling the wins support parameter in the [global] section of the configuration file, like this:
[global] wins support = yes
The wins.dat file was mentioned in Chapter 2 while discussing Samba's database files. It is important to remember that the file does not reflect the current state of nmbd's WINS database, but rather a snapshot of the registered names at a previous point in time. The file is read when nmbd starts and is synchronized with the in-memory tables periodically.
Samba 3.0 cannot currently replicate its database with any other WINS servers. If you are using Samba as your WINS server, you must make sure not to allow any Windows systems or other Samba servers on your network to be configured as WINS servers. If you do, their WINS databases will not synchronize, resulting in potentially inconsistent name resolution.
220.127.116.11. Proxying name resolution requests to DNS
Because Windows tries all possible mechanisms for translating a name to an IP address, a client might ask a WINS server to resolve the name of a server that has no relation to a NetBIOS service. For example, when a web browser tries to access an unqualified hostname, the name could be checked against Samba's WINS service. Therefore, unless configured otherwise, a Samba WINS server checks with the system's DNS server if a requested hostname (of type <00> or <20>) cannot be found in its WINS database. The nmbd daemon spawns a child process to handle the DNS lookups, so that the main process can continue to handle other incoming name requests. This method is similar to Microsoft's WINS and DNS implementation, which can share records in a common database.
Typical Unix systems maintain the IP address of the DNS server in /etc/resolv.conf. The following configuration file indicates that the host should append a domain of plainjoe.org to unqualified hostnames when sending queries to the DNS server located at 192.168.1.56:
domain plainjoe.org search plainjoe.org nameserver 192.168.1.56
If you would prefer to restrict nmbd to search only its WINS database when answering name resolution requests, disable the dns proxy option in smb.conf:
[global] wins support = yes dns proxy = no
This option has no effect if Samba's WINS server functionality has not been enabled.
18.104.22.168. Catching WINS database modifications
The wins hook global option allows you to run a script or other program whenever the WINS database is modified. The script is passed four parameters that describe the modification:
When you define the WINS hook parameter in smb.conf, provide the absolute path to the external utility, as shown here:
[global] wins support = yes wins hook = /usr/local/bin/dns_update
The original design goal of this parameter was to provide a mechanism by which nmbd could synchronize a dynamic DNS server with a its WINS database. The dns_update script referred to in the previous smb.conf example is included in the examples/scripts/wins_hook directory of the Samba distribution.
8.1.3. Setting Up Samba to Use Another WINS Server
You can configure Samba to use one or more WINS servers somewhere else on the network by providing it with their IP addresses as values to the wins server directive:
[global] wins server = 192.168.1.2 192.168.1.3
The two servers in this example implicitly belong to a single, logical WINS group. It is assumed that the all servers within a group share a synchronized databases of registered names. Samba directs WINS registration and resolution requests to the first server in the group, failing over to the next host only when the first is unavailable.
The wins support and the wins server parameters are mutually exclusive; you cannot simultaneously offer Samba as the WINS server and use another system as the server. Typically, one Samba server is set up as the WINS server using wins support, and all other Samba servers are configured with the wins server parameter pointing to the Samba WINS server.
22.214.171.124. Configuring a WINS proxy
If you have a Samba server on a subnet that contains clients but has no WINS server, and the Samba server has been configured to use a WINS server on another subnet, you can tell the nmbd server to forward any name-resolution requests with the wins proxy option:
[global] wins server = 192.168.1.2 192.168.1.3 wins proxy = yes
Use this only in situations where the WINS server resides on another subnet. Otherwise, the broadcast will reach the WINS server regardless of any proxying.
8.1.4. The lmhosts File
Chapter 3 explained how Windows systems can make use of an LMHOSTS file as an alternative to the WINS server for name resolution. Although its use is discouraged, Samba also can use an lmhosts file (default /usr/local/samba/lib/lmhosts). Samba's lmhosts follows a limited form of the syntax provided by the Windows equivalent. A simple Samba lmhosts file might look like this:
192.168.1.1 TUMNUS 192.168.1.10 TURKISH
The names on the right side of the entries are NetBIOS names, so you can assign resource types to them and add additional entries for computers:
Here, we've made TUMNUS the primary domain controller of the NARNIA domain. This line starts with TUMNUS's IP address, followed by the name NARNIA and the resource type <1B>.
If you wish to place an lmhosts file somewhere other than the default location, notify the nmbd process upon startup by using the -H option, followed by the name of your lmhosts file. However, because there is curently no way to instruct smbd to read an lmhosts from a location other than the one defined when the binaries were compiled, it is best to simply use the path returned from smbd -b | grep LMHOSTSFILE (or to avoid its use entirely).
8.1.5. Configuring Name Resolution for the Samba Suite
Daemons and tools in the Samba suite need to perform name resolution for internal use. For example, when smbd is required to contact a remote domain controller or smbclient connects to a host, Samba must act as a name resolution client. You can define the order in which the programs try each name-resolution method through the name resolve order parameter, like this:
[global] name resolve order = wins lmhosts hosts bcast
The parameter value list may be made up of up to four strings:
The order in which the values are specified is the order in which name resolution is attempted. In our example, Samba attempts to use its WINS server first for name resolution (if one has been specified), followed by the lmhosts file on the local system (if it exists). Next, the hosts value tells it to ask the operating system to resolve the name. This is possible only if the name is for a server (a resource byte of <00> or <20>) or a domain controller.[*] Finally, if those three attempts fail, the server performs a broadcast name resolution.
8.1.6. Name-Resolution Configuration Options
A summary of Samba's name-resolution options discussed in this chapter is shown in Table 8-1.