On Sun, 04 Jan 2004 07:40:33 EST, Hector Santos
<winserver(_dot_)support(_at_)winserver(_dot_)com> said:
(For the list - Another few protocol nit mentioned later on - I seem to be
noticing
them this week :)
I ask because I have learned a few things lately about the current design of
our DNS MX resolver resulting from an initial investigation why Microsoft
Window socket function gethostbyname() returned the same IP address for a
single MX, multi-home (multiple A records) domain. The DNS A record lookup
shows a load balancing/sharing (rotation of the A records), but
gethostbyname() seems to return its internal cache for the single MX
exchange name lookup.
Remember that round-robin is for the *server cluster*'s convenience, not the
client's. It's so that *overall*, clients are evenly distributed across the
round-robin list and don't all pile on the first one. In fact, a single client
can't even tell round-robin is in use unless you ask several times (I once had
the luck of doing a 'dig' of a address I *knew* was round-robined from the
server listed in the NS (so any caching at my end didn't matter), and I had to
ask *five times* before I got a different list. I just happened to be the N'th
querie 4 times in a row, so it had round-robined back to where I was)...
So that's actually permissible, as long as it obeys the TTL on the cached entry
and re-resolves it if it gets stale. Although any single host that does
caching doesn't get the benefit of the round-robin, that's OK because an
application SHOULD (rfc sense) try the A records one at a time. Yes, that's
sub-optimal if you cached a list that has the downed host first in a list of 4,
but hopefully only 1/4 of the hosts end up in that situation.
Well, looking at how DNS resolves an MX lookup, our design to use
gethostbyname() seems to be incorrect and redundant since the A record(s)
may be returned with the MX query.
However, it's not guaranteed. As you notice below...
what should I do with?
aol.com MX preference = 15, mail exchanger = mailin-03.mx.aol.com
aol.com MX preference = 15, mail exchanger = mailin-04.mx.aol.com
where there is no A records for these exchanged returned in the MX query?
As I said, not guaranteed. Your need to look these A records up as well.
You are allowed to optimize and not look them up *if* the A-less MX'x are
secondaries and as a result may not actually get referenced. Wait till you
need them. If you're really clever, you'll fire the lookup when your original
list is "getting low", so the DNS lookups happen in parallel with the last few
tries of A records, balancing "don't make un-needed queries unless you have to"
with "don't stall waiting for queries".
Similarly for yahoo.com the final list would be based on my new lookup
logic:
mx2.mail.yahoo.com internet address = 64.157.4.78
mx2.mail.yahoo.com internet address = 64.156.215.5
mx2.mail.yahoo.com internet address = 64.156.215.6
mx1.mail.yahoo.com internet address = 64.157.4.79
mx1.mail.yahoo.com internet address = 64.156.215.7
mx4.mail.yahoo.com internet address = 66.218.86.156
mx4.mail.yahoo.com internet address = 66.218.86.253
mx4.mail.yahoo.com internet address = 66.218.86.254
mx4.mail.yahoo.com internet address = 67.28.114.32
mx4.mail.yahoo.com internet address = 216.155.197.63
RFC2821, section 5, says:
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.
The destination host (perhaps taken from the preferred MX record) may
be multihomed, in which case the domain name resolver will return a
list of alternative IP addresses. It is the responsibility of the
domain name resolver interface to have ordered this list by
decreasing preference if necessary, and SMTP MUST try them in the
order presented.
So you're required to exhaust your list of mx1/mx2 A records first, then
try the mx4 A records. You're required to randomize whether you try mx1
or mx2 first. However, the spec does *not* say what to do if you have
multiple A records from multiple MX:
1) It's unclear if you should try the first mx1, the first mx2, the second mx1,
the second mx2, or first try all the mx1 and then all the mx2.
2) It's unclear if you encounter a duplicate address you've tried already on
ONE mx
if you should remove it from the list, or re-try if it's the other MX.
If the Protocol Police are going to write a ticket for this one, we need to
clean
it up so the Protocol Lawyers and Protocol Judge don't spend all afternoon
arguing. ;)
pgpjYT56QJRPi.pgp
Description: PGP signature