MX Record Theories
Mark_Andrews at isc.org
Tue May 26 18:51:43 CDT 2009
In message <163001.1243364471 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu
> Content-Type: text/plain; charset=us-ascii
> On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-nanog at 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
> % 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 at 4096 -> EDNS0 at 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 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 NANOG