Hello all,
First, I hope this is not off-topic for NANOG, please be gentle with me as this is my first post.
I
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 ? Do you have experience in
more than one of these methods and which do you favour ?
To illustrate my question :
(1)
If you query the MX records for, Hotmail or AOL you will receive 4
equal weight MX records, each of the MX records having a round-robin
set of IPs.
e.g.
hotmail.com. 2706 IN MX 5 mx4.hotmail.com.
hotmail.com. 2706 IN MX 5 mx1.hotmail.com.
hotmail.com. 2706 IN MX 5 mx2.hotmail.com.
hotmail.com. 2706 IN MX 5 mx3.hotmail.com.
-and-
mx3.hotmail.com. 1926 IN A 65.xxxxxxx
mx3.hotmail.com. 1926 IN A 65.xxxxxxx
mx3.hotmail.com. 1926 IN A 65.xxxxxxx
etc.etc.
(2)
Alternatively, some people, particularly the ones that use hosted
filtering, tend to have one MX record, which as multiple round robin
IPs.
e.g.
microsoft.com. 780 IN MX 10 mail.global.frontbridge.com.
-and-
mail.global.frontbridge.com. 1728 IN A 65.xxxxxxx
mail.global.frontbridge.com. 1728 IN A 207.xxxxxxx
etc. etc.
(3) And others simply have a more traditional setup using multiple MX records and only one IP per MX record with no round robin
apple.com. 931 IN MX 10 mail-in14.apple.com.
apple.com. 931 IN MX 20 mail-in3.apple.com.
apple.com. 931 IN MX 20 eg-mail-in2.apple.com.
etc.etc.
So
what's the big deal ? Please note I'm not asking which is "better" ...
I am just curious and interested to hear your professional opinions and
experiences.
Personally, I favour the simple option 3, multiple MX records.
Thanks y'all.
I don't think there is no real answer for your question.
It depends on each company's business objective, the cost, network
topology, and their policy.
MX record is the the mechanism for mail delivery procotol.
It doesn't dictate how to implement.
Depending on mail volume, and network policy, you can implement actual
mail servers within DNS/SMTP protocol.
There are multiple ways to get things done.
Depending on budget, business objective, network resource/policy,
you can choose the way that fits to your need.
It is same as Microsoft Windows operating system.
Microsoft release the Windows, but it doesn't say you have to run it as
cluster or not.
Depending on your need, and your own analysis/decision, you can run
whatever you like.
Alex
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* providers:
% 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. 
I 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 ? Do you have experience in
more than one of these methods and which do you favour ?
apple.com. 931 IN MX 10 mail-in14.apple.com.
apple.com. 931 IN MX 20 mail-in3.apple.com.
apple.com. 931 IN MX 20 eg-mail-in2.apple.com.
etc.etc.
Use this when only the front server is fully capable of processing the
mail into the domain. The other servers will have to hold some or all
of the mail until the first server or its cold spare returns to
service. Or perhaps the secondary servers are fully capable but
undesirable for some other reason, such as slower hardware or older
versions of the software.
microsoft.com. 780 IN MX 10 mail.global.frontbridge.com.
-and-
mail.global.frontbridge.com. 1728 IN A 65.xxxxxxx
mail.global.frontbridge.com. 1728 IN A 207.xxxxxxx
Use this when you have multiple front-end servers any of which is
fully capable of handling all messages entering the system. Free load
balancer built into the protocol.
hotmail.com. 2706 IN MX 5 mx4.hotmail.com.
hotmail.com. 2706 IN MX 5 mx1.hotmail.com.
hotmail.com. 2706 IN MX 5 mx2.hotmail.com.
hotmail.com. 2706 IN MX 5 mx3.hotmail.com.
-and-
mx3.hotmail.com. 1926 IN A 65.xxxxxxx
mx3.hotmail.com. 1926 IN A 65.xxxxxxx
mx3.hotmail.com. 1926 IN A 65.xxxxxxx
Use this when you have a large number of front-end servers fully
capable of handling messages entering the system -and- you're somewhat
clueful.
The difference is that you want the IP addresses of the servers to be
included as "additional" information in the DNS response. If you have
a large number of addresses, they're all under the same name and
including them all would make the DNS response packet larger than a
few hundred bytes, the server will drop the additional information,
requiring a second DNS lookup and possibly a third TCP-based DNS
lookup in order to get it. By splitting them up, the DNS server will
pack as many sets of addresses as it can into the original response
packet.
Regards,
Bill Herrin
Hi,
I thought i'd give you a quick response (and welcome to NANOG) :).
Thanks.
I can't believe that I've already received three very interesting responses in just over an hour !
I've been quietly lurking on NANOG for a while, just plucked up the courage to post ..... and might now even find a bit more courage to attempt to contribute to some threads !
Glad to see the community spirit still exists !
Keep the replies coming if there are any still on their way ..... 
Tim
P.S. Valdis Kletnieks ..... I've got the feeling that this ....
That 507 is critically important
if it's true, might potentially explain a few intermittent unexplicable issues we've been seeing at some sites .... time for some research me thinks....
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.
-BobbyJim
If you add enough recipients to an email, each domain within the send line
needs to have an associated MX record.
Well, it needs to resolve to an A RR somehow, but for each domain name, you get a different query.
DNS by default starts with UDP which
has a limit to the datagram size (64bit).
The UDP minimum datagram size that must be supported by DNS implementations is 512 bytes. The maximum is 64K bytes. Obviously if you try to send a 64K byte packet, it's going to fragment and as we all know, fragments are bad.
A flag is placed in the
header which then requires the request to be sent via TCP (160bit V4).
If the response to a query won't fit in the UDP buffer (512 by default, although modern client implementations can advertise a larger buffer with EDNS0), the server will signal truncation in the response (with the TC bit), typically resulting in the client retransmitting the request via TCP.
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.
IPv6 packets are a bit larger, but not that much. DNSSEC is where the fun starts.
Regards,
-drc