nanog mailing list archives
Re: MX Record Theories
From: William Herrin <herrin-nanog () dirtside com>
Date: Tue, 26 May 2009 15:12:34 -0400
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
Current thread:
- MX Record Theories gb10hkzo-nanog (May 26)
- Re: MX Record Theories Alex H. Ryu (May 26)
- Re: MX Record Theories Valdis . Kletnieks (May 26)
- Re: MX Record Theories Mark Andrews (May 26)
- Re: MX Record Theories Bobby Mac (May 28)
- Re: MX Record Theories David Conrad (May 28)
- Re: MX Record Theories Mark Andrews (May 28)
- Re: MX Record Theories William Herrin (May 26)
- Message not available
- Re: MX Record Theories gb10hkzo-nanog (May 26)
- <Possible follow-ups>
- Re: MX Record Theories gb10hkzo-nanog (May 27)
- Message not available
- Re: MX Record Theories gb10hkzo-nanog (May 28)
- Message not available