MX record preference values (was Re: Help with errors from Dlint?)

Jim Reid jim at rfc1035.com
Tue Aug 15 14:32:27 UTC 2000


>>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:

    >> Jim Reid wrote:

    >> Oh and an MX preference value of 0 is probably not a good idea
    >> either: what if you need to install another MX record with a
    >> lower preference value?

    Kevin> I realize this practice has a long history, but I've never
    Kevin> really understand the rationale. So what's the big deal
    Kevin> with *changing* the preference value of the existing MX
    Kevin> record(s) if you need to leapfrog another record ahead of
    Kevin> it/them?

Because the old MX record could be cached at places that are not
nice. Like the name server(s) used by the host that was the original MX
record target. Whenever that host receives mail for the domain in
question, it'll do a lookup and get that cached answer back. The host
will see that it is the target of the lowest (only?) MX record and
then attempt local delivery of the mail. After all, that's what an MX
preference value of 0 means. There can't be a lower value, so this
*must* be where the mail gets delivered, right? The end result is mail
bounces (maybe) or ends up in mailboxes on the wrong mail server.

Changing the MX records works fine. But this usually requires that the
configurations of all the affected mail systems (and the caches of the
name servers they use) are changed simultaneously. This should be
straightforward at a small site where there's one administrator
responsible for everything. In large organisations, this may not be
true. For instance a typical exercise could be: "migrate the London
office from the Notes server in Paris to an Exchange server in Berlin".

Another point is that in an emergency - say when the mail server is
flooded with spam or address book viruses - adding a new, lower
preference MX record will be the quickest and simplest way to reduce
the load on that mail server. ie Make a short-term quick and dirty
hack so that there's breathing space to deal with the actual problem.



More information about the bind-users mailing list