15.3 MX Records

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 

mail


                                   


                                   
hostname of our mail hub

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      13 

wash.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.8
        

28800

        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).