Section 8.1. Name Resolution


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:

  • Looking up the name in its cache of recently resolved names

  • Querying DNS servers

  • Using a local hosts file

  • Querying WINS servers

  • Using a local LMHOSTS file

  • Performing broadcast name resolution

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.

Development code in Samba 4 supports the Windows WINS replication protocol and communicates with other WINS servers. Although this code is not part of the current Samba production releases, it can be installed as a separate service to handle your WINS infrastructure.


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

8.1.2.2. 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:

  • The command that was executed: add, delete, or refresh

  • The name being modified

  • The resource byte in hex of the name being modified

  • The TTL of the request

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.

8.1.3.1. 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:

 192.168.1.1     NARNIA#1B 

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

A bug existed in all versions of Samba 3.0 up until 3.0.21b that resulted in a failure to read any lmhosts filename specified using the -H option to nmbd. This is perhaps a testimony to how little lmhosts files are used on Samba servers.


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:


lmhosts

Uses the Samba server's local lmhosts file.


hosts

Uses the standard Unix name-resolution methods provided by the gethostbyname( ) C library call. Depending on how the server's operating system is configured, this call may result in a local hosts file lookup or a query to some name service such as DNS.


wins

Use the WINS server, which may be the local Samba system itself, defined in smb.conf.


bcast

Use a broadcast name resolve query.

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.

[*] Chapter 10 explains how Samba is able to use DNS when locating domain controllers for Active Directory domains.

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.

Table 8-1. Name-resolution options

Parameter

Value

Description

Default

Scope

wins support

boolean

Controls whether nmbd will function as a WINS server.

no

Global

wins server

string (IP address or DNS name)

Identifies one or more WINS servers to use for name registration and resolution.

None

Global

wins proxy

boolean

Allows Samba to act as a proxy to a WINS server on another subnet.

no

Global

wins hook

string

External command to run when the WINS database changes.

None

Global

dns proxy

boolean

If set to yes, allows a Samba WINS server to search DNS if it cannot find a server name in WINS.

yes

Global

name resolve order

string

The order of methods used to resolve NetBIOS names.

lmhosts wins host bcast

Global





Using Samba
Using Samba: A File and Print Server for Linux, Unix & Mac OS X, 3rd Edition
ISBN: 0596007698
EAN: 2147483647
Year: 2004
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net