I have run across this before, as a matter of fact, this is the third time I've seen it on the list, and that doesn't count the threads I may have skipped.
aka, MS doesn't know how to run their MXs to scale to the volume of mail hotmal/msn receive.
I say this is very much an issue of the (windows) platform they have chosen for their MXs, specifically the (probably very highly tweaked, if not totally re-written) MX SMTP SVC they run on their windows MXs.
It has to do with a very poor choice of DNS layout, and despite Len blaming MS
huh? MS owns money-losing hotmail and msn. Let's take a wild shot in the dark and assume that MS employees run hotmail/msn DNSs and MXs with Windows software.
it really comes down to the nit wit in charge of designing the MX layout for MSN and Hotmail
... is an MS employee, no?
, which could easily have been a Unix admin for some other ISP, it has nothing to do
with platform.
of course it does.
they have 4 MX records, looks real nice, until you realize that some twit has each record pointing to RoundRobin A records
"resource record sets" are specified and perfectly legal in DNS.
Using an rr-set for MX records has been shown to be "best practice", for years, by the much more successful MX setups at aol and yahoo, works perfectly well, as first level of load distribution.
, this should be banned by the RFC's if it is not.
why? your thorough misunderstanding of both DNS and MX algorithm is not a basis for changing RFCs.
They actually have 16 MX servers
well, msn/hotmail do have a bit of inbound mail (and tons of spam) to handle, don't they?
(4 per MX), with as few as 4 down servers, your mail server could think they are completely down (your A queries are unlucky enough to get the 4 down IP's, you won't requery until ttl expires).
"you" speak for your MTA, not for everybody's. And do you even know exactly the Imail implementation of the MX algorithm?
and are your sure, or even know if, your local DNS cache is set to rotate/randomize the physical order of records?
iow, TTL has nothing to do with an IP not responding.
The MX algorithm works like this (I'm not making this up):
Try all MXs at higher preference level before trying MXs at lower preference levels.
# dig hotmail.com mx +short 5 mx3.hotmail.com. 5 mx4.hotmail.com. 5 mx1.hotmail.com. 5 mx2.hotmail.com
... the physical order of these records is determined by your local DNS server, NOT by MS's DNS.
"try an MX" will cause, for the above rr-set, the MTA to query for the MX3 hostname A's, which in hotmail (and yahoo and aol) case, will return multiple A records:
# dig mx3.hotmail.com. +short 65.54.253.99 64.4.50.179 64.4.50.239 65.54.167.5
... the physical order of these records is determined by your local DNS server, NOT by MS's DNS.
The MTA tries to the "first" A record (physically "first' in the answer section of the DNS response packet for the MX hostname query).
... so 65.54.253.99 fails. At this point, MTA MX implementations most certainly differ:
a) one implementation might sequence through the other A's for mx3.hotmail.com, while...
b) another implementation might try no other IPs for mx3, but proceed to query for, in othe above order, mx4, mx1, mx2.
Using rr-sets for MX records and for A records achieves a first-level of load distribution (not load balancing) across a) the MX records and b) the A records. EXACTLY what good MX/DNS design is looking for.
Note that MX/A rr-sets by themselves do not scale well to very high volumes (it's been tried), so, eg AOL, also uses a global "load balancing" hardware dynamically to add/delete MX's A records (with low TTL of 300s) as the MX machines are ready/undready.
I personally have seen as may as 6 servers down.
For robust, correct implementations of MX/A rr-set processing, 6 of 16 would not be fatal, since there are 10 available.
AOL "load balancing" would have dynamically pulled these 6 down IPs out of A records, and they would have expired from your local DNS cache in 300s max, so your MTA would try to deliver to down IPs.
MS apparently leaves bad IPs in DNS records, thank you, once again, MS. Such a tactic could be intentional on MS's part, since they know darn well, as we all do, they have a huge mail problem, and forcing our MXs to waste their time trying dead MS IPs is a way of tarpitting all of Internet (so inbound mail rate to MS is reduced).
Pehaps IMail's implementation of the MX algorithm is not the best (see above), combined with MS's crappy MX/DNS design and MX machines, give us the headaches will all see periodically with hotmail.
Len
_____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
