In message <163001.1243364471@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu writes:
--==_Exmh_1243364471_3846P Content-Type: text/plain; charset=us-ascii
On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-nanog@yahoo.co.uk said:
would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ?
The trick here is that it isn't always *exactly* "the same goal". There's multiple mail system architectures and design philosophies.
One often overlooked but very important design point for the *large* provider s:
% dig aol.com mx ;; ANSWER SECTION: aol.com. 2805 IN MX 15 mailin-01.mx.aol.com. aol.com. 2805 IN MX 15 mailin-02.mx.aol.com. ... ;; WHEN: Tue May 26 14:40:41 2009 ;; MSG SIZE rcvd: 507
That 507 is critically important if you want to receive e-mail from sites with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;)
Actually TCP/53 out is almost always allowed. Too many things break if you block TCP/53 out. Similarly TCP to recursive servers is almost always allowed because blocking it breaks too many things. Recursive nameservers generally deal with stupid firewalls by adjusting how they make their queries. EDNS0@4096 -> EDNS0@512 -> plain DNS. Stub resolvers generally don't do EDNS so the are not impacted by stupid firewalls. This will changes as DNSSEC processing moves into the application. A EDNS referral from the root servers to the COM servers already exceeded 512 bytes. The world hasn't fallen over. That's dealt with that myth. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org