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 gb10hkzo-nanog@yahoo.co.uk wrote:
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.
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* 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. ;)
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
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 On Tue, May 26, 2009 at 2:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
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* 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. ;)
On May 28, 2009, at 5:04 AM, Bobby Mac wrote:
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
In message <c3de0a330905280804t56ca87dapd94281399202a48@mail.gmail.com>, Bobby Mac writes:
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.
As I said, sites just don't do this as it causes serious problems. Sites that disable TCP/53 outbound just end up re-enabling it. Nameservers and stub resolvers automatically retry with TCP and the client applications just don't get answers returned when you start blocking TCP/53 outbound. It doesn't take long for said stupidity to be reversed.
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.
The number of recipients has no impact on the size of the DNS responses. It will have a impact on the number of DNS queries made iff the receipents are in multiple mail domains. Mark
-BobbyJim -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, May 26, 2009 at 2:03 PM, <gb10hkzo-nanog@yahoo.co.uk> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (8)
-
Alex H. Ryu -
Bobby Mac -
David Conrad -
gb10hkzo-nanog＠yahoo.co.uk -
Mark Andrews -
Mark Andrews -
Valdis.Kletnieks＠vt.edu -
William Herrin