I'll bet you're drowsy, too, after that looong chapter. Thankfully, this chapter discusses a topic that should be very interesting to you system administrators and postmasters: how DNS impacts electronic mail. And even if it isn't interesting to you, at least it's shorter than the last chapter.
One of the advantages of the Domain Name System over host tables is its support of advanced mail routing. When mailers had only the HOSTS.TXT file (and its derivative, /etc/hosts) to work with, the best they could do was to attempt delivery to a host's IP address. If that failed, they could either defer delivery of the message and try again later, or bounce the message back to the sender.
DNS offers a mechanism for specifying backup hosts for mail delivery, and also for allowing hosts to assume mail handling responsibilities for other hosts. This lets diskless hosts that don't run mailers, for example, have mail addressed to them processed by their server.
DNS, unlike host tables, allows arbitrary names to represent electronic mail destinations. You can -- and most organizations on the Internet do -- use the domain name of your main forward-mapping zone as an email destination. Or you can add domain names to your zone that are purely email destinations and don't represent any particular host. A single logical email destination may also represent several mail servers. With host tables, mail destinations were hosts, period.
Taken all together, these features give administrators much more flexibility in configuring electronic mail on their networks.
Early experience with DNS on the ARPAnet showed that separating the functions didn't work very well. A mailer needed both the MD and MF records attached to a domain name (if both existed) to decide where to send mail -- one or the other alone wouldn't do. But an explicit lookup of one type or another (either MD or MF) would cause a name server to cache just that record type. So mailers either had to do two queries, one for MD and one for MF records, or they could no longer accept cached answers. This meant that the overhead of running mail was higher than that of running other services, which was eventually deemed unacceptable.
The two records were integrated into a single record type, MX, to solve this problem. Now a mailer just needed all the MX records for a particular domain name destination to make a mail routing decision. Using cached MX records was fine, as long as the TTLs matched.
MX records specify a mail exchanger for a domain name; this is a host that will process or forward mail for the domain name (through a firewall, for example). " Processing" the mail means either delivering it to the individual it's addressed to or gatewaying it to another mail transport, like X.400 or Microsoft Exchange. "Forwarding" means sending it to its final destination or to another mail exchanger "closer" to the destination via SMTP, the Internet's Simple Mail Transfer Protocol. Sometimes, forwarding the mail involves queuing it for some amount of time, too.
In order to prevent mail routing loops, the MX record has an extra parameter besides the domain name of the mail exchanger: a preference value. The preference value is an unsigned 16-bit number (between and 65535) that indicates the mail exchanger's priority. For example, the MX record:
specifies that relay.hp.com is a mail exchanger for peets.mpk.ca.us at preference value 10.peets.mpk.ca.us. IN MX 10 relay.hp.com.
Taken together, the preference values of a destination's mail exchangers determine the order in which a mailer should use them. The preference value itself isn't important, only its relationship to the values of other mail exchangers: is it higher or lower than the values of this destination's other mail exchangers? Unless there are other records involved:
does exactly the same thing as:plange.puntacana.dr. IN MX 1 listo.puntacana.dr. plange.puntacana.dr. IN MX 2 hep.puntacana.dr.
Mailers should attempt delivery to the mail exchangers with the lowest preference values first. It may seems a little counterintuitive at first that the most preferred mail exchanger has the lowest preference value. But since the preference value is an unsigned quantity, this lets you specify a "best" mail exchanger at preference value 0.plange.puntacana.dr. IN MX 50 listo.puntacana.dr. plange.puntacana.dr. IN MX 100 hep.puntacana.dr.
If delivery to the most preferred mail exchanger(s) fails, mailers should attempt delivery to less preferred mail exchangers (those with higher preference values) in order of increasing preference value. That is, mailers should try more preferred mail exchangers before they try less preferred mail exchangers. More than one mail exchanger may share the same preference value, too, giving the mailer its choice of which to send to first. The mailer must try all the mail exchangers at a given preference value before proceeding to the next higher value.
The newest version of sendmail, Version 8, will actually choose randomly among mail exchangers with the same preference.For example, the MX records for oreilly.com might be:
Interpreted together, these MX records instruct mailers to attempt delivery to oreilly.com by sending to:oreilly.com. IN MX 0 ora.oreilly.com. oreilly.com. IN MX 10 ruby.oreilly.com. oreilly.com. IN MX 10 opal.oreilly.com.
Note that oreilly.com isn't a particular host; it's the domain name of O'Reilly & Associates' main forward-mapping zone. O'Reilly & Associates uses the domain name as the email destination for everyone who works there. It's much easier for correspondents to remember the single email destination oreilly.com than to remember which host -- ruby.oreilly.com? amber.oreilly.com? -- each employee has an email account on.
This requires, of course, that the mailer on ora.oreilly.com keep track of which host each user at O'Reilly & Associates has an email account on. That's usually done by maintaining a master aliases file on ora.oreilly.com that forwards email from ora.oreilly.com to its eventual destination.
What if a destination doesn't have any MX records, but it has one or more A records? Will a mailer simply not deliver mail to that destination? Actually, you can compile recent versions of sendmail to do just that. Most vendors, however, have compiled their sendmails to be more forgiving: if no MX records exist but one or more A records do, they'll at least attempt delivery to the address. Version 8 of sendmail compiled "out of the box" will try the address of a mail destination without MX records. Check your vendor's documentation if you're not sure whether your mail server will send mail to destinations with only address records. Even though nearly all mailers deliver mail to a destination with just an address record and no MX records, it's still a good idea to have at least one MX record for each legitimate mail destination. When it has mail to deliver, sendmail always looks up the MX records for a destination first. If the destination doesn't have any MX records, a name server -- usually one of your authoritative name servers -- still must answer that query, and then sendmail goes on to look up A records. That takes extra time, slows mail delivery, and adds a little load to your zone's authoritative name servers. If you simply add an MX record for each destination pointing to a domain name that maps to the same address that an address lookup would return, sendmail has to send only one query, and the mailer's local name server caches the MX record for future use.
|4.10. What Next?||5.2. What's a Mail Exchanger, Again?|
Copyright © 2002 O'Reilly & Associates. All rights reserved.