Minimizing Pain and Suffering (DNS and BIND, 4th Edition)

6.3. Minimizing Pain and Suffering

Now that you've configured your host to use DNS, what's going to change? Will your users be forced to type long domain names? Will they have to change their mail addresses and mailing lists?

Thanks to the search list, much of this will continue working as before. There are some exceptions, though, and some notable differences in the way that some programs behave when they use DNS. We'll try to cover all the common ones.

6.3.1. Differences in Service Behavior

As you've seen earlier in this chapter, programs such as telnet, ftp, rlogin, and rsh apply the search list to domain name arguments that aren't dot-terminated. That means that if you're in movie.edu (i.e., your local domain name is movie.edu and your search list includes movie.edu), you can type either:

% telnet misery

or:

% telnet misery.movie.edu

or even:

% telnet misery.movie.edu.

and get to the same place. The same holds true for the other services, too. There's one other behavioral difference you may benefit from: because a name server may return more than one IP address when you look up an address, modern versions of Telnet, FTP, and web browsers try to connect to the first address returned, and if the connection is refused or times out, for example, they try the next, and so on:

% ftp tootsie
ftp: connect to address 192.249.249.244: Connection timed out
Trying 192.253.253.244...
Connected to tootsie.movie.edu.
220 tootsie.movie.edu FTP server (Version 16.2 Fri Apr 26
    18:20:43 GMT 1991) ready.
Name (tootsie: guest):

And remember that with the resolv.conf sortlist directive, you can even control the order in which your applications try those IP addresses.

One oddball service is NFS. The mount command can handle domain names just fine, and you can put domain names into /etc/fstab (your vendor may call it /etc/checklist), too. But watch out for /etc/exports and /etc/netgroup. /etc/exports controls which filesystems you allow various clients to NFS-mount. You can also assign a name to a group of hosts in netgroup and then allow them access via exports by using the name of the group.

Unfortunately, older versions of NFS don't really use DNS to check exports or netgroup -- the client tells the NFS server its identity in an RPC (Remote Procedure Call) packet. Consequently, the client's identity is whatever the client claims it is, and the identity a host uses in Sun RPC is the local host's hostname. So the name you use in either file needs to match the client's hostname, which isn't necessarily its domain name.

6.3.2. Electronic Mail

Some electronic mail programs, including sendmail, also don't work as expected; sendmail doesn't use the search list quite the same way that other programs do. Instead, when configured to use a name server, it uses a process called canonicalization to convert names in electronic mail addresses to full, canonical domain names.

In canonicalization, sendmail applies the search list to a name and looks up data of type ANY, which matches any type of record. sendmail uses the same rule newer resolvers do: if the name to canonicalize has at least one dot in it, check the name as-is first. If the name server queried finds a CNAME record (an alias), sendmail replaces the name looked up with the canonical name the alias points to and canonicalizes that (in case the target of the alias is itself an alias). If the name server queried finds an A record (an address), sendmail uses the domain name that resolved to the address as the canonical name. If the name server doesn't find an address but does find one or more MX records, one of the following actions is performed:

If the search list has not yet been appended, sendmail uses the domain name that resolved to the MX record(s) as the canonical name.
If one or more elements of the search list have been appended, sendmail notes that the domain name is a potential canonical name and continues appending elements of the search list. If a subsequent element of the search list turns up an address, the domain name that turned up the address is the canonical name. Otherwise, the domain name that found the first MX record is used as the canonical name.[41]
[41]All this complexity is necessary to deal with wildcard MX records, which we'll discuss in Chapter 16, "Miscellaneous".

sendmail uses canonicalization several times when processing an SMTP message; it canonicalizes the destination address and several fields in the SMTP headers.[42]

[42]Some older versions of sendmail use a different technique for doing canonicalization: they apply the search list and query the name server for CNAME records for the name in question. CNAME matches only CNAME records. If a record is found, the name is replaced with the domain name on the right-hand side of the CNAME record.

sendmail also sets macro $w to the canonicalized hostname when the sendmail daemon starts up. So even if you set your hostname to a short, single-part name, sendmail canonicalizes the hostname using the search list defined in resolv.conf. sendmail then adds macro $w and all aliases for $w encountered during canonicalization to class $=w, the list of the mail server's other names.

This is important because class $=w names are the only names sendmail recognizes, by default, as the local host's name. sendmail will attempt to forward mail that's addressed to a domain name it thinks isn't local. So, for example, unless you configure sendmail to recognize all of the host's aliases (by adding them to class w or fileclass w, as we showed in Chapter 5, "DNS and Electronic Mail" ), the host will try to forward messages that arrive addressed to anything other than the canonical domain name.

There's another important implication of class $=w, which is that sendmail recognizes only the contents of class $=w as the local host's name in MX lists. Consequently, if you use anything other than a name you're sure is in $=w in the right side of an MX record, you run the risk that the host will not recognize it. This can cause mail to loop and then be returned to the sender.

One last note on sendmail: when you start running a name server, if you're running an older version of sendmail (before Version 8), you should set the I option in your sendmail.cf file. Option I determines what sendmail does if a lookup for a destination host fails. When using /etc/hosts, a failed lookup is fatal. If you search the host table once for a name and don't find it, it's doubtful it'll miraculously appear later, so the mailer may as well return the message. When using DNS, however, a lookup failure may be temporary, because of intermittent networking problems, for example. Setting option I instructs sendmail to queue mail if a lookup fails instead of returning it to the sender. Just add OI to your sendmail.cf file to set option I.

6.3.3. Updating .rhosts, hosts.equiv, etc.

Once you start using DNS, you may also need to disambiguate host names in your host's authorization files. Entries that use simple, one-part host names will now be assumed to be in the local domain. For example, the lpd.allow file on wormhole.movie.edu might include:

wormhole
terminator
diehard
robocop
mash
twins

If we move mash and twins into the comedy.movie.edu zone, though, they won't be allowed to access lpd; the entries in lpd.allow allow only mash.movie.edu and twins.movie.edu. So we'd have to add the proper domain names to host names outside the lpd server's local domain:

wormhole
terminator
diehard
robocop
mash.comedy.movie.edu
twins.comedy.movie.edu

Some other files you should check for host names in need of domain-ification are:

hosts.equiv
.rhosts
X0.hosts
sendmail.cf

Sometimes, simply running these files through a canonicalization filter -- a program that translates host names to domain names using the search list -- is enough to disambiguate them. Here's a very short canonicalization filter in Perl to help you out:

#!/usr/bin/perl -ap
# Expects one hostname per line, in the first field (a la .rhosts,
# X0.hosts)

s/$F[0]/$d/ if ($d)=gethostbyname $F[0];

6.3.4. Providing Aliases

Even if you cover all your bases and convert all your .rhosts, hosts.equiv, and sendmail.cf files after you configure your host to use DNS, your users will still have to adjust to using domain names. Hopefully, the confusion they feel will be minimal and more than offset by the benefits of DNS.

One way to make your users' lives less confusing after configuring DNS is to provide aliases for well-known hosts that are no longer reachable using their familiar names. For example, our users are accustomed to typing telnet doofy or rlogin doofy to get to the bulletin board system run by the movie studio on the other side of town. Now they'll have to start using doofy's full domain name, doofy.maroon.com. But most of our users don't know the full domain name, and it'll be some time before we can tell all of them and they get used to it.

Luckily, BIND lets you define aliases for your users. All we need to do is set the environment variable HOSTALIASES to the pathname of a file that contains mappings between aliases and domain names. For example, to set up a system-wide alias for doofy, we could set HOSTALIASES to /etc/host.aliases in the system's shell startup files and add:

doofy    doofy.maroon.com

to /etc/host.aliases. The alias file format is simple: the alias starts the line in column one, followed by whitespace and then the domain name that corresponds to the alias. The domain name is written without a trailing dot, and the alias can't contain any dots.

Now when our users type telnet doofy or rlogin doofy, the resolver transparently substitutes doofy.maroon.com for doofy in the name server query. The message the users see now looks something like:

Trying...
Connected to doofy.maroon.com.
Escape character is '^]'.
IRIX System V.3 (sgi)
login:

If the resolver falls back to using /etc/hosts, though, our HOSTALIASES won't have any effect. So we should also keep a similar alias in /etc/hosts.

With time, and perhaps a little instruction, the users will start to associate the full domain name they see in the telnet banner with the bulletin board they use.

With HOSTALIASES, if you know the domain names your users are likely to have trouble with, you can save them a little frustration. If you don't know which hosts they're trying to get to, you can let your users create their own alias files, and having each user point the HOSTALIASES variable in his shell startup file to his personal alias file.