Recall that in the hub/client setup, all mail goes to the hub machine and none is ever delivered directly to the client. This requires two things: that all mail to the client be automatically sent to the hub machine instead of to the client and that the hub machine accept mail addressed to the client as though that mail were addressed to the hub machine instead. Forcing all mail to go to the hub machine requires special Mail Exchanger (MX) records.
If you already administer DNS, the changes that we will make are easily accomplished. If you don't, you will have to ask your DNS administrator to make the changes for you. How DNS interacts with sendmail is described in greater detail in Chapter 21, DNS and sendmail. You may want to jump ahead to that chapter, and then return here, to better understand the changes we are making.
To arrange for all mail to go to the hub machine, first find the primary file for your DNS zone. We won't tell you where to find it, because either you know where it is or you probably lack permission to edit it. Somewhere in the primary file for your DNS zone is an entry for the local client. It looks something like this:
here IN A 123.45.67.8 IN HINFO Sun4/75 unix
Remember that the local machine is here.us.edu. The entry for
this machine begins with its hostname (with the domain part
omitted). The IN
says that this is an Internet-type
entry - the only type that is currently supported. The A
says that this is an address record, one that associates
an IP address with a hostname. The IP address is the dotted
quad that follows (the 123.45.67.8
).
Other lines may follow the A record. Here, we show an HINFO (host information) record that describes the hardware and the operating system for the local machine.
Immediately below the A record for the local machine, add a new MX record:
here IN A 123.45.67.8 IN MX 13 mail add IN HINFO Sun4/75 unix
Two pieces of information are necessary for
an MX record. The first is a relative
preference (the 13
), which must be a number.
The preference is used only when there is more than one
MX record for a host. If there were two, the host with
the lower preference would be tried first and then the host with
the higher preference if the first failed.
The number that is selected doesn't
matter, because there is only one MX record for this host.
The second item (the one following the preference) is the name
of the hub machine to which mail will be sent in place of sending
it to the client. If the domain part for both the hub machine
and the client machine is the same, only the hostname of the
hub machine needs to appear in this record. The hostname
of the hub in all our examples has been mail
,
so that is what we used:
IN MX 13
You should, of course, replace mail
with the actual name
of your central mail-handling machine.
If the hub machine is in a different domain than the client,
a fully qualified domain name needs to be specified in place of
mail
.
For example, if all local mail is being sent offsite
to the central server at wash.dc.gov, the following would appear:
IN MX 13wash.dc.gov.
note the dot at the end
If you place a fully qualified name in an MX record,
be sure to terminate that name with a dot. That dot tells DNS
that this name is complete. Without it, DNS automatically
appends your local domain to the name, resulting in an unknown address.
In the entry mail
above, the dot was omitted because
mail
is in the local domain.
After you've made this change, you need to wait for the old
record to time out. The length of time to wait depends on the value
of the Time To Live (TTL) that is defined for the record. A TTL can
appear in two places. It can appear in the A record,
or it can appear elsewhere as a default TTL. If the TTL appears in
the A record, it will be a number between the hostname
and the IN
:
here 28800 IN A 123.45.67.8 Time To Live (TTL) for this record
TTL values are always in seconds. Here, the A record will time out and any new information will be updated after eight hours have elapsed. Depending on when it was last updated, you may have to wait up to eight hours for the new MX record to be recognized.
If the A record has a TTL, you should duplicate that TTL in the new MX record so that they both time out together:
here 28800 IN A 123.45.67.828800
IN MX 13 mail
At most sites the TTL for A and MX records are not
stored with them but are defined by a default TTL elsewhere.
To find the default TTL, look at the top of the same file for a
Start Of Authority (SOA
) record:
@ IN SOA us.edu. postmaster.us.edu. ( 1.43 ; serial number 7200 ; secondary refresh 1800 ; secondary retry 3600000 ; secondary expire 86400 ) ; default ttl
The details of your SOA
record will differ, but the
desired information can still be found. The SOA
record
includes a parenthetical list of five numbers. The last
is the default TTL that will be used for all records that don't
specify one. Here, that default
is 86400 seconds, or 24 hours.
If your MX records lack individual TTLs (because the A record lacks them), you will need to wait the default TTL period of time for the new MX record to become known.
We've omitted a few wrinkles, such as reloading the name server, for a simpler description of the process. If you have permission to change the zone file, you have doubtless changed it before and are familiar with the missing steps. If you haven't, a short section like this one can't begin to give you the information you need to manage DNS. Instead, we refer you to DNS and BIND, Second Edition by Paul Albitz and Cricket Liu (O'Reilly & Associates, Inc., 1997).