UNIX hosts and MX "best practice"

[Kevin Darcy]

Barry Margolin wrote:

> In article <38923337.923869FC at sas.upenn.edu>,
> John H. Yates <yates at sas.upenn.edu> wrote:
> >What is considered "best practice" for UNIX hosts these days? To
> >assign a UNIX host its MX record as itself, or to leave it unspecified?
>
> Any name that you expect to be used frequently after '@' in email addresses
> should have an MX record.
>
> >I've observed that it falls back to the A record if you don't bother
> >specifying it, but it makes "nslookup" MX queries look "different" than
> >I am used to, and I was just wondering what current "best practice" is.
>
> Falling back to the A record is required, since the purpose of MX is to
> specify an alternate place to send mail instead of sending it to the host
> itself.  However, there are performance implications if you don't have an
> MX record.  The sending machine always has to query for an MX record first.
> If its local DNS server doesn't have the MX record in its cache, it can't
> tell if this is because there is no MX record or because it just hasn't
> looked it up recently enough to have it in cache, so it has to query an
> authoritative server (negative caching improves this somewhat, since it
> will remember recent failures, but many DNS servers don't implement ncache
> or limit the negative cache timeout severely).  After this query fails, the
> mailer will query for the A record, which will presumably be in its local
> server's cache.
>
> But if there's an MX record, the first query will succeed immediately with
> the cached record.

Newer sendmails use ANY queries to avoid this performance problem. Assuming other
mailers follow suit, eventually all of those "matching" MX records should become
obsolete, at which point they can be omitted to reduce cache size.

I wonder, though, if the proliferation of new query types (SIG, NXT, SRV, to
mention a few) might end up ballooning the size of ANY-query responses to the
point where it makes more sense to go back to the old-fashioned way.


- Kevin