MX Record Theories

Tue May 26 23:51:43 UTC 2009

In message <163001.1243364471 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu
 writes:
> --==_Exmh_1243364471_3846P
> 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
> 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 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org