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

[Mathias Körber]

> -----Original Message-----
> From: jim at gromit.rfc1035.com [mailto:jim at gromit.rfc1035.com]On Behalf =
Of
> Jim Reid
> 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.


But surely, even that host will not learn a new MX record with lower =
prio
until it has expired the older record from its cache. It has no need
to look up a better record as it still has a valid resource record in
that RRset.

So adding an MX record with lower prio on the primary, having it =
propagated
to the secondaries etc will not have any influence on any system that
has MX records for the same label still cached.



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

But again, a nameserver that has a valid MX record in its cache for a =
given
label will not look for a better prio until all others have expired.
So there is no need to keep some lower numbers unused, one can always =
just renumber
the others. Propagation does not change at all.

Mathias