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.
sendmail uses canonicalization several times
when processing an SMTP message; it canonicalizes the destination
address and several fields in the SMTP headers.
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
), 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.
|
