Mx round robin issue with 4.9
Mark Andrews
Mark_Andrews at isc.org
Wed Aug 16 14:21:09 UTC 2006
> I am sure someone would be amazing we were still using 4.9. anyway.
>
> We are upgrading a legacy server from 4.9 to 8.x. After the upgrade,
> the email folks realize that mail flow works better. I went back to the
> old version to do test, discover that the MX records with the same
> preference does not rotate in the 4.9 version.
>
> For example, we have these entries defined in the file:
> op.com. IN MX 10 mroim01.fmr.com.
> op.com. IN MX 10 mmkim02.fmr.com.
> mroim01.fmr.com. IN a 10.200.1.20
> mmkim02.fmr.com. IN a 10.187.2.20.
>
> When do nslookup against 4.9. it always retune in the order of
> op.com MX preference = 10, mail exchanger =mroim01.fmr.com
> op.com MX preference = 10, mail exchanger =mmkim02.fmr.com
>
> When do nslookup against 8.x server, the order changes for each request,
> which is round robin.
>
> Does anyone know if there is a bug in 4.9 for MX round robin. I remember
> that there was a bug in earlier version bind with round robin. I would
> like to confirm that my assumption is correct.
BIND 4.9 didn't have round robin. Round robin was add to
BIND 4.9.2.
RFC compliant MTA's will randomly select between equal
preference MX records. There is no requirement for MX
records to be returned in a different order. In particular
round robin is extremely bad when there are multiple
preferences involved.
As you can see this has been a requirement for the last 17 years.
RFC 1123 (October 1989)
(1) Multiple MX Records -- these contain a preference
indication that should be used in sorting. If there are
multiple destinations with the same preference and there
is no clear reason to favor one (e.g., by address
preference), then the sender-SMTP SHOULD pick one at
random to spread the load across multiple mail exchanges
for a specific organization; note that this is a
refinement of the procedure in [DNS:3].
RFC 2821 (April 2001)
Multiple MX records contain a preference indication that MUST be used
in sorting (see below). Lower numbers are more preferred than higher
ones. If there are multiple destinations with the same preference
and there is no clear reason to favor one (e.g., by recognition of an
easily-reached address), then the sender-SMTP MUST randomize them to
spread the load across multiple mail exchangers for a specific
organization.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users
mailing list