MX Record Theories
bobbyjim at gmail.com
Thu May 28 10:04:47 CDT 2009
Not entirely on subject but.... I thought that allowing DNS queries to
occur via TCP is mission critical for simple mail routing. We ran across
this back in the day at @Home Network. Firewall rules were changed to not
allow port 53 TCP. This severely affected sending mail to large
distribution lists. Here is what we found and forgive me if I don't go into
too much detail as it was almost 10 years a go.
If you add enough recipients to an email, each domain within the send line
needs to have an associated MX record. DNS by default starts with UDP which
has a limit to the datagram size (64bit). A flag is placed in the
header which then requires the request to be sent via TCP (160bit V4). Now
that single query can be split up into many different packets providing that
the request is more than the 160 bit and obviously IPV6 offers even more
information contained in a single packet.
On Tue, May 26, 2009 at 2:01 PM, <Valdis.Kletnieks at vt.edu> wrote:
> 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*
> % 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. ;)
More information about the NANOG