MX Record Theories

William Herrin herrin-nanog at dirtside.com
Tue May 26 19:12:34 UTC 2009


On Tue, May 26, 2009 at 2:03 PM,  <gb10hkzo-nanog at 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 at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004




More information about the NANOG mailing list