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

[Kevin Darcy]

Jim Reid wrote:

> >>>>> "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?

This is just a propagation issue, and has nothing to do with the absolute
values of the preference fields. sendmail, for instance, doesn't treat a 0
preference in any special way. The rule (RFC 974) is to delete all records
from the MX list with a preference equal to or greater than the local
host's. So whether that preference is 0, 10, 100, 65535 or whatever, if
you delete the MX'es and end up with an empty list, it's an error
condition. Using a non-zero preference value doesn't hurt or help this
situation.

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

Again, this is a propagation issue and has nothing to do with the actual
preference values used.

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

Yet again, a propagation issue. Granted, there might be some old
nameservers out there which are still merging partial RRsets, so that
mailservers using those nameservers may temporarily see multiple
preference-0 MX'es and would start randomizing between the "good" and
"bad" targets. But RFC 2181 forbids this nameserver behavior, so the
problem, if it still exists at all, should disappear before long.


- Kevin