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 184.108.40.206 IN HINFO Sun4/75 unix
Remember that the local machine is
. The entry for
this machine begins with its hostname (with the domain part
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 220.127.116.11 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
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
IN MX 13
You should, of course, replace
If the hub machine is in a different domain than the client,
a fully qualified domain name needs to be specified in place of
IN MX 13
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
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
here 28800 IN A 18.104.22.168 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 22.214.171.124
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 (
@ 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
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).