 | Chapter 6 Configuring Hosts |  |
| Chapter 6 Configuring Hosts | |
UNIX is ostensibly a standard operating system, but there are almost as many UNIX standards as flavors of UNIX. Likewise, there are almost as many different styles of resolver configuration as there are UNIXes. Almost all support the original Berkeley syntax, but most add nonstandard enhancements or variations, too. We'll cover as many of the major styles of resolver configuration as we can.
Configuring a host running SunOS can be a challenge. The behavior of the SunOS resolver is arguably as different from that of standard DNS as major vendors get - primarily because SunOS's resolver is integrated with Sun's Network Information Service, or NIS (n�e Yellow Pages).
NIS, briefly, provides a mechanism for keeping important files synchronized between hosts on a network. This includes not just /etc/hosts, but also /etc/services, /etc/passwd, and others. Sun positions DNS as a backup option to NIS; if the NIS resolver can't find a host name (or IP address) in the NIS hosts map, you can configure it to query a name server.
Note that the resolver functionality is implemented as part of the ypserv program, which also handles other types of NIS queries. So if ypserv isn't running, neither is your resolver! (Mercifully, the resolver in Solaris 2 doesn't require that you run ypserv.) One benefit of using ypserv to resolve all queries is that you don't need to configure the resolvers on NIS clients, only on NIS servers.[9] The NIS clients will query an NIS server for host data, and the NIS server will query DNS, if necessary.
[9] Actually, you also need to configure the resolver on hosts on which you use sendmail.mx, Sun's MX-smart version of sendmail.
If you run SunOS 4.X (Solaris 1), you can (1) follow the party line and configure your resolver to use DNS as a backup to NIS, (2) choose to run NIS without host maps, or (3) buck convention and recompile your resolver to use DNS exclusively - or you can pick up free copies of modified resolvers on the Internet. However, we must warn you that, according to our sources, Sun will not support the modified resolver option.
If you run Solaris 2, you can simply configure the resolver like a normal human being. You also have control over the order in which the resolver consults various naming services via the nsswitch.conf file.
We won't go into much detail about this option here, primarily because this process is now well-documented and nearly automated in the newest DNS distribution. The process itself usually involves creating a new libc.so - the standard, shared C library - by pulling out routines that call NIS and replacing them with pure DNS versions. Although Sun generously provides the necessary replacement routines, they don't support them. Worse, the routines supplied with SunOS 4.1 were based on DNS 4.8.1.
If you have the latest DNS source distribution, look for instructions on installing the DNS 8.1.2 resolver routines under SunOS in the package's src/port/sunos/shres subdirectory, currently in a file called INSTALL.
If you'd rather skip the potentially edifying experience of creating your own shared C library and leverage someone else's efforts, you can check out resolv+, based on the DNS 4.8.3 resolver.
resolv+ is an enhanced version of the 4.8.3 resolver routines for SunOS, written by Bill Wisner, which allows administrators to choose the order in which NIS and DNS are queried (much like the extensions other vendors have added to UNIX, which we'll discuss later). The new routines are available, with instructions on how to build them into libc.so, from ftp.uu.net as the file /networking/ip/dns/resolv+2.1.1.tar.Z. For more information on the functionality resolv+ provides, see the Linux section later in this chapter.
If you go the socially acceptable route, though, you'll need to make NIS and DNS coexist peacefully. That's a little tricky, so we'll go over it in some detail. We won't cover how to set up NIS - that's already been covered in gory detail in Hal Stern's Managing NFS and NIS (O'Reilly & Associates, 1991). Note that these instructions only apply to versions of SunOS after 4.1. If you run an older version of SunOS, consider the replacement libraries on ftp.uu.net.
First, you'll need to modify the Makefile NIS uses to build its maps - the files that it distributes to other hosts on the network. You should make this modification on the master NIS server, not on the slaves.
The NIS Makefile lives in /var/yp/Makefile on a SunOS host. The change you need to make is simple: you need to uncomment one line and comment another. Find the lines that read:
#B=-b B=
and change them to read:
B=-b #B=
Then rebuild your NIS hosts map:
#cd /var/yp#rm hosts.time#make hosts.timeupdated hosts pushed hosts
This will insert a "magic cookie" into the hosts map that instructs NIS to query DNS if it can't find a host name in the hosts map. Now, when the ypserv program looks up a name, it will check the appropriate hosts map for the local NIS domainname, and if it can't find the name there, it will query a name server. The search list ypserv uses when it queries the name server is derived from either the local NIS domainname or from the domain directive in resolv.conf.
Next, you should create a resolv.conf file, if you need one. The rules for configuring the resolver change slightly with SunOS:
You can't set the hostname to a domain name and have the resolver infer the local domain.
You also can't use the search directive in resolv.conf, since the SunOS 4.1.1 resolver is based on DNS 4.8.1. The resolver will silently ignore it.
You can set the NIS domainname to a domain name (you have to set it to the name of your NIS domain if you're using NIS), and the resolver will derive the name of the local DNS domain from it. However, this doesn't work quite the same way it does with DNS; if you set domainname to fx.movie.edu, for example, the search list will only include movie.edu. Why doesn't the search list include fx.movie.edu? Because NIS assumes it's already checked an authoritative source of fx.movie.edu host data - the fx.movie.edu hosts map.
If you want to set the default domain to the same name as your NIS domainname, you can prepend a dot or a plus ("+") to the domainname. To set your default domain to fx.movie.edu, you could set domainname to either +fx.movie.edu or .fx.movie.edu.
You can also override NIS's normal behavior by setting the local domain with the domain directive in resolv.conf. So if you wanted to force the resolver to include fx.movie.edu in the search list, you could add domain fx.movie.edu to resolv.conf.
You can even set the domain directive in resolv.conf to a DNS domain name totally unrelated to your NIS domainname. In some unfortunate situations, the local NIS domainname isn't the same as, or even similar to, the DNS domain name. Say the Information Technology Department at Movie U. originally set up the NIS domain it.dept.movieu, and still uses it. To prevent spurious DNS queries in the nonexistent dept.movieu domain, hosts in this NIS domain should be configured with domain movie.edu (or something similar) in resolv.conf.
Finally, Sun's resolv.conf treats the nameserver directive just as vanilla DNS does. So once you're done inserting magic cookies and configuring your NIS domainname and possibly your DNS domain, you can add any name servers to resolv.conf and be done.
If you want to retain Sun's support but would rather not use icky NIS, you still have an option: you can run NIS with an empty hosts map. First, set up your resolv.conf file, then insert the magic cookie into the NIS Makefile as we described in the preceding section, "Using DNS with NIS," and create an empty hosts map. Creating an empty hosts map just requires moving the NIS master server's /etc/hosts file aside temporarily, generating your hosts NIS map, then replacing the /etc/hosts file:
%mv /etc/hosts /etc/hosts.tmp%touch /etc/hosts # to keep make from complaining%cd /var/yp%make hosts.timeupdated hosts pushed hosts %mv /etc/hosts.tmp /etc/hosts
Now, when the resolver checks NIS, it won't find anything, and will go directly to querying a domain name server.
If you periodically rebuild your NIS maps, you should make sure the hosts map doesn't accidentally get rebuilt from /etc/hosts. The best way to do this is to remove the hosts target from the NIS Makefile. You can just comment out everything in the Makefile from the line that begins with:
hosts.time: $(DIR)/hosts
The resolver in Solaris 2 through 2.5.1 is based on the DNS 4.8.3 resolver, with extensions to give you the ability to determine the order in which the resolver consults the "sources:" DNS, NIS, and /etc/hosts. The resolver in Solaris 2.6 is based on the DNS 4.9.3 resolver, with the same extensions.[10] This service order is configured in a file called nsswitch.conf, which lives in the /etc directory.
[10] You can get patches to update Solaris 2.5 and 2.5.1 to DNS 4.9.3 via anonymous ftp from sunsolve1.sun.com in /pub/patches. Check http://sunsolve.sun.com/sunsolve/pubpatches/patches.html for the current patch numbers.
Actually, nsswitch.conf is used to configure the order in which a number of different services are resolved. Individual services, called databases in Sun's parlance, are selected by a keyword. For naming services, the database name is hosts. The possible sources are dns, nis, nisplus, and files (which refers to /etc/hosts, in this case). Configuring the order in which the sources are consulted is a simple matter of listing them after the database name in that order. For example:
hosts: dns files
has the resolver try DNS (i.e., query a name server) first, then check /etc/hosts. By default, resolution moves from one source to the next (e.g., falls back to /etc/hosts from DNS) only if the first source isn't available. You can modify this behavior by using several other criteria to determine when to move on to the next source. The possible criteria are:
The service hasn't been configured (in DNS's case, there is no resolv.conf file, and there is no name server running on the local host).
The service can't find the name or address in question.
The service isn't currently available (for example, because the resolver has timed out while trying to look up a name).
For each of these criteria, you can specify that the resolver should either continue or return. For example, if you want the resolver to check /etc/hosts if DNS isn't configured or if DNS can't find the name, you can use:
hosts: dns [NOTFOUND=continue UNAVAIL=continue] files
If you want a DNS NXDOMAIN (no such domain name) answer to halt the search for the name, you'd use:
hosts: dns [NOTFOUND=return]
The default Solaris resolver behavior, by the way, is determined by the answers you give SunInstall.
In recent versions of Solaris 2.X, including 2.5 and later, Sun introduced a name service cache daemon, called nscd. nscd caches the results of lookups in the passwd, group, and hosts databases. You can think of nscd as very similar to a caching-only name server, except that it also works for information in passwd and group databases. Sun's intent with nscd was to speed up performance by caching frequently-looked-up names. Unfortunately, word on the street is that nscd sometimes slows DNS lookups, and many people disable it. Moreover, nscd interferes with round robin (nscd caches records in one order and doesn't rotate them).
nscd is started by default during a multiuser bootup, and reads the configuration file /etc/nscd.conf. Administrators can tune a number of parameters in nscd.conf. The most important of these are:
Determines whether or not nscd caches the results of host lookups
Determines how long nscd caches positive results (e.g., addresses), in seconds
Determines how long nscd caches negative results (e.g., NXDOMAIN), in seconds
If you're not convinced of nscd's usefulness, at least with DNS lookups, you can use:
enable-cache hosts no
to turn caching off for the hosts database.
HP's resolver implementation is basically straight DNS; the HP-UX 8.0 and 9.0 resolvers are based on DNS 4.8.3, and support the standard domain, nameserver, and search directives. The order in which a host consults DNS, NIS, and the host table is hard-wired. The host will use DNS if DNS is configured. If DNS isn't configured, and NIS is running, the host will use NIS. If neither DNS nor NIS is running, the host will use the host table. The host only falls back to using the other services under the circumstances described earlier in the chapter (i.e., the resolver only uses one name server - either listed in resolv.conf or on the local host by default - and four errors are received while contacting that name server).
The hard-wired algorithm is less flexible than what other vendors provide, but it's easy to troubleshoot. When you can consult DNS, NIS, and the host table in any order, diagnosing user problems can be awfully difficult.
The HP-UX 10.30 resolver is based on DNS 4.9.3, and patches are available for all versions of 10.X to upgrade the server and ancillary programs to DNS 4.9.6. To gain access to the patches, visit the HP-UX patch archive at http://us-support.external.hp.com/ and register. You can then search the patch database for the latest patches.
HP-UX 10.0 introduced Solaris's nsswitch.conf functionality; that is, you can use nsswitch.conf to control the order in which the resolver consults the various naming services.[11] The syntax is exactly the same as that used in Solaris's nsswitch.conf. The default settings for the hosts database under HP-UX are:
[11] Before HP-UX 10.10, you could only use nsswitch.conf to configure order of resolution for the hosts database. From 10.10 on, you can also use nsswitch.conf to configure resolution order for the services, networks, protocols, rpc, and netgroup databases.
hosts: dns nis files
This functionality is also available in patches for HP-UX 9.0. Check the web-based HP-UX patch archive for these. You may need quite a few patches:
One for the standard, shared C library, libc.so, which contains the resolver routines in HP-UX
One for the mount command, which is statically linked
One for nslookup
One for the ifconfig and route commands
One for HP's Visual User Environment (VUE), which is shipped statically linked
The HP-UX 10.30 resolver also supports the DNS 4.9.3 search list behavior and the options ndots directive.
The resolver shipped with the current version of AIX, 4.2.1, is also relatively standard. The code is based on DNS 4.9.3, so it understands the domain, search, nameserver, options, and sortlist directives; AIX supports up to three nameserver directives. AIX versions 4 and 4.1 were based on DNS 4.8.3, so they handle all the directives AIX 4.2.1's resolver does except options and sortlist.
One difference between AIX's behavior and the stock BSD behavior is that AIX uses the existence of the resolv.conf file to determine whether to query a name server. If resolv.conf doesn't exist on the local host, the resolver reads /etc/hosts. This means that on a host running a name server, you should create a zero-length /etc/resolv.conf file, even if you don't intend to put any directives in it.
IBM has also modified the resolver so that it checks NIS and then /etc/hosts, even if DNS claims there's no such domain name or no such data. This gives you the ability to add hosts to /etc/hosts temporarily, before they make it into the name server, and will let you maintain your own host-specific name-to-address mappings.
AIX 4.2.1 also includes a mechanism to control resolution order similar to Solaris's nsswitch.conf. AIX uses a file called /etc/netsvc.conf. Like nsswitch.conf, netsvc.conf calls the database hosts, but uses an equals sign between the database name and the sources instead of a colon, uses commas between sources, uses bind for DNS, and uses local for /etc/hosts. So:
hosts = local,nis,bind
has the AIX resolver check the local /etc/hosts first, then check the NIS hosts map, and finally try DNS. Individual users or processes can override the system-wide resolution order configured with netsvc.conf by setting an environment variable, NSORDER. NSORDER uses the same syntax netsvc.conf does, minus the database name and equal sign. So to change the resolution order for your user to check DNS first and then /etc/hosts, ignoring NIS, you could run:
%NSORDER=bind,local; export NSORDER
AIX 3.2's resolver was based on the DNS 4.8.1 resolver, so it doesn't understand the search directive. It exhibits the same peculiarities with respect to the existence of resolv.conf that the 4.1 resolver does. For those of you with older AIX 3.2 installations, there is a patch, PTF U412845, that will let you shorten the resolver timeout so that AIX will fall back to /etc/hosts more quickly than normal. There are also instructions on using Bill Wisner's resolv+ package with AIX in the AIX FAQ, posted periodically to comp.unix.aix and archived on rtfm.mit.edu in /pub/usenet/news.answers/aix-faq/. Use at your own risk. For more information on resolv+'s functionality, see the Linux section later in this chapter.
We should also note that you can configure the resolver using AIX's System Management Interface Tool (SMIT).
The resolver shipped with the most recent version of Digital UNIX, 4.0D, is based on the DNS 4.9.3 resolver. As such, it understands all five resolver directives covered in this chapter.
Digital UNIX allows you to configure the order in which the resolver checks NIS, DNS, and the host table via a file called svc.conf (see the svc.conf(5) manpage).[12] svc.conf also allows you to configure which services are consulted for other "databases," including mail aliases, authentication checks (mapping from IP address to host or domain names), password and group information, and a slew of other things.
[12] Digital's "other" UNIX operating system, Ultrix, also supports svc.conf.
To configure the resolver with svc.conf, use the database name hosts, followed by an equals sign and the keywords for the services you want checked, separated by commas, in the order you want them checked. The legal keywords for hosts are local (the local host table), yp (for "Yellow Pages," the old name for NIS), and bind (for DNS). local must be the first service listed for hosts. Don't use any whitespace on the line, except (optionally) after commas and at the end of the line.
The line:
hosts=local,bind
instructs the resolver to check /etc/hosts for host names first, and if no match is found, to use domain name service. This is very useful when the host has a small local host table that includes the local host's domain name and IP address, the host's default router, and any other hosts referenced during startup. Checking the local host table first avoids any problems using domain name service during startup, when networking and named may not have started.
Digital UNIX also includes a utility called svcsetup (see the svcsetup(8) manpage), which allows you to set up the svc.conf file interactively, without the aid of an editor. Typing svcsetup will throw you into a mode where you can choose the database you'd like to configure, and will prompt you for the order of the services you want checked.
As of IRIX 6.2, IRIX has a DNS 4.9.3 name server, but the resolver is still essentially 4.8.3. There are also patches available to bring the server up to DNS 4.9.4. For the current patch numbers, see http://support.sgi.com/surfzone/patches/browse/index.html (you'll need to register if you aren't already a SurfZone member).
The IRIX resolv.conf file, which lives in /usr/etc/resolv.conf, adds a hostresorder directive. The hostresorder directive allows the administrator to determine the order in which NIS, DNS, and the local host table are searched. Individual users can set the environment variable HOSTRESORDER to determine the order in which the services are used for their commands.
hostresorder takes one or more of the keywords nis, bind, and local as arguments. (The keywords correspond to the obvious services.) The keywords may be separated by either whitespace or a slash. Whitespace indicates that the next service should be tried if the previous service doesn't return an answer (e.g., the name isn't found in the host table, or the name server returns "no such domain") or isn't available (e.g., the name server isn't running). A slash indicates that the preceding service is authoritative, and if no answer is returned, resolution should stop. The next service is tried only if the previous isn't available.
The newest release of SCO's UNIX operating system, Open Server 5.0.X, has a resolver based on the DNS 4.9.2 resolver. As a 4.9.2-derived resolver, it understands all of the normal directives (including sortlist and options!) in resolv.conf plus hostresorder. hostresorder works exactly the same way it does in IRIX (see the section on IRIX immediately preceding this section); the keywords are the same (bind, nis, and local), and a slash, instead of a space, indicates that the preceding service is authoritative and the search should return if that service doesn't find the name. The default setting (without hostresorder configured) is equivalent to:
hostresorder bind nis local
Also, even if resolution order isn't explicitly configured, if DNS and NIS aren't available, the resolver will use /etc/hosts.
You can override anything configured with domain, options, or hostresorder in resolv.conf with the environment variables LOCALDOMAIN, RES_OPTIONS, and HOSTRESORDER, respectively. For example, to change resolution order to DNS-only and the options to set ndots to 1 before starting sendmail, you could run:
%HOSTRESORDER="dns"; RES_OPTIONS="ndots:1"%export HOSTRESORDER RES_OPTIONS%/usr/lib/sendmail -bd -q1h
Since we first published this book, Linux has taken the computing world by storm. A couple of the reasons are that Linux is freeware, and that it does a better job of keeping up with developments in the UNIX and Internet communities than any vendor's version of UNIX. Attesting to that is the fact that RedHat Linux 5.1, the latest version of one of the predominant strains of Linux, ships with a DNS 4.9.6 resolver and server. The resolver also supports Sun's nsswitch.conf file.
However, some older Linux resolvers are based on Bill Wisner's resolv+ library, which is in turn based on DNS 4.8.3. Consequently, the resolv.conf file can include any legit 4.8.3 resolver directives (domain, search, and nameserver, but not options) and has the older default search list described in this chapter.
resolv+, as the name suggests, also provides several enhancements over the standard 4.8.3 resolver. They include the ability to determine the order in which DNS, NIS, and /etc/hosts are consulted (replaced by the more standard nsswitch.conf in newer versions), the ability to detect certain types of DNS spoofing, and the ability to reorder address records in replies to favor local subnets.
All of these enhancements are controlled by the /etc/hosts.conf file. The most interesting keywords that hosts.conf accepts are:
Controls the order in which the various name services are consulted; the valid arguments are bind, hosts, and nis, at least one of which must follow the keyword. Multiple arguments must be separated by commas.
Takes the single argument on or off. nospoof instructs the resolver to check any reverse mapping (PTR) information it gets from remote name servers by issuing a forward (address) query for the domain name in the reply. If the address returned by the address query isn't the same as the address the resolver originally tried to reverse map, the PTR record is ignored.
Takes the single argument on or off. With reorder on, the resolver sorts the addresses of multiply-homed hosts so that any address on a local subnet appears first.
Windows 95, the successor to the popular Windows operating system, includes its own TCP/IP stack with a DNS resolver. In fact, Windows 95 actually includes two TCP/IP stacks: one for TCP/IP over LANs, and another for TCP/IP over dialup connections. Configuration of the resolver in Windows 95 is, naturally enough, graphical. To get to the main DNS configuration panel, start the Control Panel, then select Network, then choose the TCP/IP protocol. This brings up a new dialog, which looks similar to the one in Figure 6.1. Choose the tab labeled DNS Configuration.
Configuration using this panel is fairly self-explanatory: you check Enable DNS to turn on DNS resolution, then fill in the PC's hostname (in this case, the first label of its domain name) in the Host field, and the local domain (everything after the first dot) in the Domain field. You add the IP addresses of the name servers you want to query, in the order in which you want to query them, under DNS Server Search Order. Finally, you fill in the domains in the search list under Domain Suffix Search Order in the order in which you want them applied.
One interesting note about the current version of Windows 95: you can configure a different set of name servers for each dial-up connection you might have to an Internet service provider (ISP) in the Dial-Up Networking (DUN) configuration. To configure DUN-specific resolver settings, double-click on the My Computer icon on your desktop, then double-click on Dial-Up Networking, right-click on the name of the connection whose resolver settings you'd like to configure, then select Properties. Select the Server Types tab and click on TCP/IP Settings. You'll see the window shown in Figure 6.2.
If you leave the Server assigned name server addresses radio button checked, the resolver will retrieve the name servers it should query from the DHCP server you dial into. If you check Specify name server addresses and specify the addresses of one or two name servers, Windows 95 will try to use those name servers when the DUN connection is active.
This is really useful if you use multiple ISPs and each has its own name servers. However, configuring name servers in the TCP/IP Properties panel overrides the DUN-specific name servers. To use the DUN-specific name server feature, you must leave the TCP/IP Properties panel blank except for enabling DNS and specifying the local hostname. This limitation is probably just an oversight due to a lack of integration between the dial-up and LAN TCP/IP stacks, and should be corrected in a future release of Windows 95.
Lest you think this is the only idiosyncrasy in the way that DNS resolution works on Windows 95, we'll point you to the Windows 95 Networking FAQ, maintained by Rich Graves, at http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html. This FAQ contains lots of valuable DNS information, including how to change the order in which the Win95 resolver uses the LMHOSTS file, WINS, and DNS.
In Windows NT, LAN resolver configuration is done from a single panel that looks remarkably similar to Windows 95's now that NT 4.0 - which includes the Windows 95 "shell" - has been released. In fact, other than the presence of handy little arrows that allow you to reorder name servers and elements of the search list, there's really no semantic difference between them, as shown in Figure 6.3.
To get to the DNS configuration panel, start the Control Panel, click on Network, and select the Protocols tab. Double-click on TCP/IP Protocol, then select the DNS tab.
Windows NT also allows the user to configure resolver settings specific to particular dialup networking connections. To configure these, click on the My Computer icon, start Dial Up Networking, pull down the top selection box and choose the name of the DUN connection whose resolver you'd like to configure. Then click on the More pull-down and select Edit Entry and Modem Properties. Select the Server tab on the resulting window, and click on the TCP/IP Settings button. You'll see the very same window you'd see in Windows 95 (shown earlier). If you leave the Server assigned name server addresses radio button checked, the resolver will retrieve the name servers it should query from the DHCP server you dial into. If you check Specify name server addresses and specify the addresses of one or two name servers, Windows NT will use those name servers when the DUN connection is active. When you drop the DUN connection, NT will revert to using the LAN resolver's settings.
|  | |
| 6.3 Minimizing Pain and Suffering |  | 7. Maintaining BIND |