Name Resolution and Browsing in Samba, Part 1

Related Reading Using Samba By Jay Ts, Robert Eckstein, David Collier-Brown Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

Editor's note: In this first of a two-part series of excerpts from Chapter 7 of Using Samba, 2nd Edition, learn how to work with name resolution using WINS. And be sure to check back here next week for Part 2 on "Browsing."

Introduction

Name resolution is critical to Samba's operation because names are used to find the servers that share files or printers. Browsing takes the task of finding servers to a new level of sophistication by allowing a user to delve down into a hierarchy of networks, domains, hosts, and services offered by each server.

While name resolution and browsing are not difficult to configure, some complexity is introduced by the variety of available name-resolution systems. Historically, Unix and other TCP/IP users have moved from a flat hosts file to the Domain Name System, with the Network Information System being another popular choice. Meanwhile, Microsoft has moved from a broadcasting system to a simple, LAN-only name server called WINS and ultimately to DNS.

The reason for going over that history is that all previous systems of name resolution are still in use today! Finding a host is so crucial to networking that sites want robust (if limited) name-resolution systems to fall back on in case the main system fails. Browsing is also complicated by the frequent need to show hosts in other subnets. This chapter shows you how to configure your network to handle name resolution any way you want.

Some of the differences between Unix and Microsoft networking implementations are the result of fundamental design goals. Unix networking was originally designed largely to implement a relatively formal group of systems that were assumed to be small in number, well-maintained, and highly available, that have static IP addresses, and that wouldn't physically move around from place to place. Bringing a new server online was a labor-intensive task, but it did not have to be performed frequently. In contrast, Windows networking was originally developed as a peer-to-peer collection of small personal computers on a single subnet, having no centrally or hierarchically organized structure.

SMB networking is dynamic. Computers are allowed to leave the network at any time, sometimes without warning, and also to join or rejoin the network at any time. Furthermore, any user in a Windows network can add a new shared resource to the network or remove a resource that he had previously added. The change in the network's configuration is handled automatically by the rest of the network without requiring a system administrator to take any action.

Name Resolution

TCP/IP networks identify systems by IP addresses and always 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 that was very simple, yet very inefficient. 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 WINS (Windows Internet Name Service) support to Windows NT so that the computers on the network can 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, how the client is configured (i.e., whether DNS server and/or WINS server IP addresses are provided), and whether the application software is accessing the network through Microsoft's Winsock or TCP/IP API. 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 the DNS Hosts file

• Querying WINS servers

• Using the WINS LMHOSTS file

• Performing broadcast name resolution

The first method is pretty much self-explanatory. A hostname is checked against a cache of hostnames that have been recently resolved to IP addresses. This helps to save time and network bandwidth for resolving names that are used frequently.

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 NT/2000 or Unix systems. You can learn more about DNS and DNS server configuration in the O'Reilly book DNS and BIND.

In this chapter, we focus mainly on name resolution using WINS, which is supported by Samba with the nmbd daemon.

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[1] 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 renew 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 will eventually be deleted.

More information on WINS can be found in the Microsoft white paper Windows Internet Naming Service (WINS) Architecture and Capacity Planning. It can be downloaded from the Microsoft web site at http://www.microsoft.com.

The lmhosts File

In Chapter 3 of Using Samba, 2nd Edition, we cover how to configure Windows systems to use the LMHOSTS file as an alternative to the WINS server for name resolution. Samba also can use an LMHOSTS file, which by default is /usr/local/samba/lib/lmhosts. Samba's lmhosts is the same format as the Windows version. A simple lmhosts file might look like this:

172.16.1.1    toltec
172.16.1.6    maya

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:

172.16.1.1    toltec#20
172.16.1.1    metran#1b
172.16.1.6    maya#20

Here, we've made toltec the primary domain controller of the METRAN domain on the second line. This line starts with toltec's IP address, followed by the name metran and the resource type <1B>. The other lines are entries for toltec and maya as standard workstations.

If you wish to place an lmhosts file somewhere other than the default location, you will need to notify the nmbd process upon startup using the -H option, followed by the name of your lmhosts file, as follows:

# nmbd -H /etc/samba/lmhosts -D

Configuring Name Resolution for the Samba Suite

Various daemons and tools in the Samba suite need to perform name resolution. 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 string used to define the parameter can take up to four values:

lmhosts

Uses the Samba server's local lmhosts file

hosts

Uses the standard Unix name-resolution methods, which can be /etc/hosts, DNS, NIS, or a combination, depending on how the local system is configured

wins

Uses the WINS server

bcast

Uses the broadcast method

The order in which they are specified is the order in which name resolution will be attempted. In our example, Samba will attempt to use its WINS server first for name resolution, followed by the lmhosts file on the local system. Next, the hosts value tells it to use Unix name-resolution methods. The word hosts can be misleading; it covers not only the /etc/hosts file, but also the use of DNS or NIS (as configured on the Unix host). Finally, if those three do not work, it will perform a broadcast name resolution.

Setting Up Samba as a WINS Server

You can set up Samba as a WINS server by setting the wins support parameter in the configuration file, like this:

[global]
	wins support = yes

Believe it or not, that's all you need to do! The wins support option turns Samba into a WINS server. For most installations, Samba's default configuration is sufficient.

WARNING: Remember, Samba cannot communicate with Windows 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 inconsistent name resolution.

Configuring a DNS proxy

A Samba WINS server can check with the system's DNS server if a requested host cannot be found in its WINS database. With a typical Linux system, for example, you can find the IP address of the DNS server by searching the /etc/resolv.conf file. In it, you might see an entry such as the following:

nameserver 127.0.0.1
nameserver 172.16.1.192

This tells us that the Linux system is configured to use a DNS server located at 172.16.1.192. (The 127.0.0.1 is the localhost address and is never a valid DNS server address.)

Now it is a simple matter of using the dns proxy option to tell Samba to use the DNS server:

[global]
	dns proxy = yes

TIP: Although this allows Windows clients to resolve fully qualified Internet domain names through the Samba WINS server, it will work only for domain names that fit within the 15-character limitation of NetBIOS names. For this reason, we recommend you use dns proxy only to act as a supplement to your WINS server, rather than as a replacement for a DNS server.

[global]
	wins server = 172.16.1.1

[global]
	wins server = 172.16.200.12
	wins proxy = yes

Samba's name-resolution options are shown in Table 7-1.

[global]
    wins support = yes

[global]
    wins server = 172.16.220.110

[global]
    wins server = wins.metran.cx

[global]
    wins proxy = yes

[global]
    wins hook = /usr/local/bin/sync_wins

[global]
    dns proxy = yes

[global]
    name resolve order = lmhosts wins hosts bcast

This causes resolution to use the lmhosts file first, followed by a query to a WINS server, the /etc/hosts file, and finally broadcasting. You need not use all four options. This option is covered in more detail in the section "Setting Up Samba as a WINS Server," earlier in this chapter.

max ttl

This option is used when Samba is not acting as a WINS server but is using another system on the network for its WINS server. It sets the maximum T T L for NetBIOS names registered by the Samba server with the WINS server. You should never need to alter this value.

max wins ttl

This option is used when Samba is providing WINS name service, and it sets the maximum T T L for NetBIOS names registered with Samba. You should never need to change this value from its default.

min wins ttl

This option is used when Samba is providing WINS name service, and it sets the minimum T T L for NetBIOS names registered with Samba. You should never need to alter this value from its default.

Check back here next week for Part 2 of this excerpt, which will cover browsing in Samba.

Return to ONLamp.com.

Copyright © 2007 O'Reilly Media, Inc.