6.3.1 Differences in Service Behavior

As you've seen earlier in this chapter, programs like 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 default domain 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 and ftp will try to connect to the first address returned, and if the connection is refused or times out, for example, it will 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 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. If the name server queried finds a CNAME record (an alias), it replaces the name looked up with the canonical name the alias points to. 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 finds one or more MX records:

• 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.[7]

  [7] All this complexity is necessary to deal with wildcard MX records, which we'll discuss in Chapter 15, Miscellaneous.

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

[8] Some older versions of sendmail use a different technique for doing canonicalization: they apply the search list and query the name server for type 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 (not to be confused with class w) to the canonicalized hostname when you freeze the sendmail.cf file, or, if you don't freeze your configuration file, when the sendmail daemon starts up. So even if you set your hostname to a short, single-part name, sendmail will canonicalize the hostname using the search list defined in resolv.conf.

This is important because the local host's canonical name is the only name 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 the host's aliases (using 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 for anything other than the canonical domain name.

There's another important implication of the way sendmail canonicalizes the local hostname - sendmail recognizes only the local host's canonical name in MX lists. Consequently, if you use anything other than a host's canonical name in 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 also 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 and refreeze it, if you use a frozen configuration file.

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 might include:

wormhole
terminator
diehard
robocop
mash
twins

If we move mash and twins into the comedy.movie.edu domain, though, they won't be allowed to access lpd; the entries in lpd.allow only allow mash.movie.edu and twins.movie.edu. So we'd have to add the proper domains to host names outside of the local host's default 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 short canonicalization filter in Perl to help you out:

#!/usr/bin/perl

# Perl canonicalization filter
#
# Expects one hostname per line, in the first field (a la .rhosts,
# X0.hosts)

use Socket;

while( < >)
    if(($hostname, $null) = split){
      ($domainname, $aliases, $addrtype, $length, @addrs) =
            gethostbyname($hostname);
      if($domainname) {s/$hostname/$domainname/;}
    }
    print;
}

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 will be 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, DNS will let 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. The alias can't contain dots.

Now, when our users type telnet doofy or rlogin doofy, the resolver will transparently substitute doofy.maroon.com for doofy in the name server query. The message the users see will look 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 have each point the HOSTALIASES variable in his shell startup file to his personal alias file.