Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

5.1 MX Records

DNS uses a single type of
resource record to implement enhanced
mail routing, the MX record. Originally, the MX
record's function was split between two records, the
MD (mail destination) and MF (mail forwarder) records. MD specified
the final destination to which a message addressed to a given domain
name should be delivered. MF specified a host that would forward mail
on to the eventual destination, should that destination be
unreachable.

Early experience with DNS on the Internet 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 mailone 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: a host that will
either process or forward
mail for the domain name (through a firewall, for example).
"Processing" the mail means either
delivering it to the individual to whom it's
addressed or gatewaying it to another mail transport, such as X.400.
"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 0 and 65535)
that indicates the mail exchanger's priority. For
example, the MX
record:

peets.mpk.ca.us.    IN    MX    10 relay.hp.com.

specifies that relay.hp.com is a mail exchanger
for peets.mpk.ca.us at preference value 10.

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
other records are involved, this:

plange.puntacana.dr.  IN  MX  1 listo.puntacana.dr.
plange.puntacana.dr.  IN  MX  2 hep.puntacana.dr.

does exactly the same thing as:

plange.puntacana.dr.  IN  MX  50  listo.puntacana.dr.
plange.puntacana.dr.  IN  MX  100 hep.puntacana.dr.

Mailers should attempt delivery to the mail exchangers with the
lowest preference values first. This may seem a
little counterintuitivethe 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.

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. This gives 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, though.

For example, the MX records for oreilly.com
might be:

oreilly.com.    IN    MX    0 ora.oreilly.com.
oreilly.com.    IN    MX    10 ruby.oreilly.com.
oreilly.com.    IN    MX    10 opal.oreilly.com.

Interpreted together, these MX records instruct mailers to attempt
delivery to oreilly.com by sending to:

ora.oreilly.com first

Either ruby.oreilly.com or
opal.oreilly.com next

The remaining preference 10 mail exchanger (the one not used in step
2)

Of course, once the mailer successfully delivers the mail to one of
oreilly.com's mail exchangers,
it can stop. A mailer successfully delivering
oreilly.com mail to
ora.oreilly.com doesn't need to
try ruby.oreilly.com or
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
hostruby.oreilly.com?
amber.oreilly.com?each employee has an
email account on.

This requires, of course, that the administrator of the mailer on
ora.oreilly.com maintain a file of aliases for
all email users at O'Reilly, forwarding their mail
to the hosts on which they read it, or run a server that offers users
remote access to their mail stores, such as a POP or IMAP server.
What if a destination doesn't have any MX records,
but has one or more A records? Will a mailer simply not deliver mail
to that destination? Well, it depends on the mail server. Both
Microsoft Exchange and the SMTP servers provided with Windows Server
2003 require the presence of a valid MX record for any domain name to
which you want to deliver mail. However,
Sendmail, a popular mail transport agent from
the Unix world, is different. Recent versions
of
Sendmail can be compiled to deliver mail to a
destination with no MX records but at least one A record. Most
vendors have compiled their Sendmails this way.
Sendmail Version 8, 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 will 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. Most mailers, including
Sendmail, will always look up the MX records for
a destination first when there is mail to deliver. If the destination
doesn't have any MX records, a name
serverusually one of your authoritative name
serversstill must answer that query, and then
Sendmail will go 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 mail destination pointing to a domain name that
maps to the same address that an address lookup would return, the
mailer will have to send only one query, and the
mailer's local name server will cache the MX
record for future use.