Multiple MX records or multple A records? - TCP-IP

This is a discussion on Multiple MX records or multple A records? - TCP-IP ; Greetings. I have a basic question about best practices with MX and A records. We have two SMTP servers available to accept E-mail addressed to our domain (amherst.edu). These servers are peers, and we wish to come as close as ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Multiple MX records or multple A records?

  1. Multiple MX records or multple A records?

    Greetings. I have a basic question about best practices with MX and A
    records. We have two SMTP servers available to accept E-mail
    addressed to our domain (amherst.edu). These servers are peers, and
    we wish to come as close as possible to load balancing between them
    via our DNS configuration. Am I better off with two MX records (one
    for each server) with identical priorities, or one MX record, but
    multiple A records?

    amherst.edu. IN MX 10 smtp1.amherst.edu.
    amherst.edu. IN MX 10 smtp2.amherst.edu.
    smtp1.amherst.edu. IN A a.b.c.d1
    smtp2.amherst.edu. IN A a.b.c.d2

    or

    amherst.edu. IN MX 10 smtp.amherst.edu.
    smtp.amherst.edu. IN A a.b.c.d1
    smtp.amherst.edu. IN A a.b.c.d2

    Is one of these considered more of a "best practice" than the other?
    Does one make life easier on the mail servers trying to send me mail?

    Thanks for any help.

    - John W. Manly Amherst College

  2. Re: Multiple MX records or multple A records?

    In article ,
    jwmanly@amherst.edu (John W Manly) wrote:

    > Greetings. I have a basic question about best practices with MX and A
    > records. We have two SMTP servers available to accept E-mail
    > addressed to our domain (amherst.edu). These servers are peers, and
    > we wish to come as close as possible to load balancing between them
    > via our DNS configuration. Am I better off with two MX records (one
    > for each server) with identical priorities, or one MX record, but
    > multiple A records?


    I think both techniques are used widely, and there's not a strong
    concensus either way. There are also some organizations that use a
    combination: multiple MX records, and each name resolves to multiple
    addresses (take a look at AOL.COM's MX records).

    The only deciding factor I can think of is that the configuration with a
    single MX record will result in smaller response messages.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***

  3. Re: Multiple MX records or multple A records?

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    jwmanly@amherst.edu (John W Manly) writes:

    >amherst.edu. IN MX 10 smtp1.amherst.edu.
    >amherst.edu. IN MX 10 smtp2.amherst.edu.
    >smtp1.amherst.edu. IN A a.b.c.d1
    >smtp2.amherst.edu. IN A a.b.c.d2


    >or


    >amherst.edu. IN MX 10 smtp.amherst.edu.
    >smtp.amherst.edu. IN A a.b.c.d1
    >smtp.amherst.edu. IN A a.b.c.d2


    >Is one of these considered more of a "best practice" than the other?
    >Does one make life easier on the mail servers trying to send me mail?


    Use the two MX records (the first solution).

    If nothing else, sendmail will randomize the order of MX records of
    the same priority, but it won't randomize A records.

    A connecting system has to lookup MX records anyway. In the second
    case, they will have receive a response with an empty data
    section, and the SOA record in the authority section. They then
    need a second DNS lookup to get the IP address.

    If the first (MX) case, the A records might be returned as part of
    the additional data in the response to the MX query. The MTA may
    still need a second lookup, but there is a good chance it can get it
    answer from its local DNS cache, without that requiring a second
    lookup to your DNS servers.

    ---

    A different consideration -- if you use STARTTLS, then the first
    solution requires that the two servers use different certificates,
    whereas with the second solution they could share the same cert
    (since they use the same name).

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (SunOS)

    iD8DBQFAiqUYvmGe70vHPUMRAndiAKCKpofucsVxhZ9xfsIspX 3ZhFAh4ACeJiRk
    rFJ0R8oTmwkhXZJ/b+IEauA=
    =YVT5
    -----END PGP SIGNATURE-----


  4. Re: Multiple MX records or multple A records?

    JWM> amherst.edu. IN MX 10 smtp1.amherst.edu.
    JWM> amherst.edu. IN MX 10 smtp2.amherst.edu.
    JWM> smtp1.amherst.edu. IN A a.b.c.d1
    JWM> smtp2.amherst.edu. IN A a.b.c.d2
    JWM> or
    JWM> amherst.edu. IN MX 10 smtp.amherst.edu.
    JWM> smtp.amherst.edu. IN A a.b.c.d1
    JWM> smtp.amherst.edu. IN A a.b.c.d2

    NWR> A connecting system has to lookup MX records anyway.

    In fact, several SMTP Relay clients perform "ANY" lookups, in order to work
    around a BIND version 4 bug that prevents them from successfully performing
    the actual "CNAME" lookup that they want to do, and attempt to re-use the
    answers that they received in response when they come to perform the
    subsequent "MX" lookups. (Of course, "ANY" is not "ALL", and such re-use is
    oftentimes not possible.)

    NWR> In the second case, they will have receive a response with
    NWR> an empty data section, and the SOA record in the authority
    NWR> section.

    Untrue. The response from the "amherst.edu." content DNS server to the
    resolving proxy DNS server will comprise the "MX" resource record set in the
    "Answer" section, and possibly the "A" resource record set for
    "smtp.amherst.edu." in the "Additional" section. The response from the
    resolving proxy DNS server to (DNS Client library in) the SMTP Relay client
    will be the same. In neither case will there be an empty "MX" resource record
    set. In neither case will an "SOA" resource record necessarily be present.

    NWR> They then need a second DNS lookup to get the IP address.

    Untrue. SMTP Relay clients only need a second DNS lookup if the resolving
    proxy DNS server didn't supply the "A" resource record set for
    "smtp.amherst.edu." in the "Additional" section of the first response. And,
    even then, resolving proxy DNS servers may well have that information already
    in their caches and have no need to issue any further back-end queries, if, in
    turn, the "amherst.edu." content DNS server supplied the "A" resource record
    set for "smtp.amherst.edu." in the "Additional" section of *its* first
    response.

    NWR> If the first (MX) case, the A records might be returned as
    NWR> part of the additional data in the response to the MX query.

    .... which is just as equally true of the second case. There is no actual
    difference between the two cases in this respect.

    NWR> The MTA may still need a second lookup, but there is a good
    NWR> chance it can get it answer from its local DNS cache,
    NWR> without that requiring a second lookup to your DNS servers.

    .... which is just as equally true of the second case, as explained.

  5. Re: Multiple MX records or multple A records?


    "Jonathan de Boyne Pollard" which method do you recommend?



  6. Re: Multiple MX records or multiple A records?

    s> "Jonathan de Boyne Pollard"

    Your punctuation is confused. You are the one with the pseudonym, not I.

    s> which method do you recommend?

    Barry has mentioned one decision criterion that favours the second.
    Another criterion that favours the first is that, as mentioned in RFC
    2821, some badly designed SMTP Relay clients may decide only to try one
    IP address from each "A" resource record set.

    There's very little to choose between them. And that's, really,
    inherent in the very nature of the mapping. What is published in the
    DNS database is, in actual fact, a mapping from a domain name to a list
    of tuples, that just happens to be in two stages.
    The intermediate domain names, that form the halfway stage of that
    mapping, should be treated as mere implementation details that convey no
    additional information by themselves. A 1->N->N mapping should be
    equivalent to a 1->1->N mapping.

    Barry's criterion does outweigh the RFC 2821 one, however. Small
    response sizes are a good thing, and an unnecessary proliferation of
    intermediate domain names is both pointless and a waste of everyone's
    cache space. Whereas SMTP Relay clients that, when connecting to SMTP
    Relay servers, don't treat multiple-member "A" resource record sets in
    the same way that any other applications would treat such "A" resource
    sets when connecting to any other services (i.e. by trying more than one
    address from the set), are badly designed and really shouldn't be
    accommodated.

+ Reply to Thread