Admin test: MTA should not require MX when AAAA is the same.

[IByte]

On the Admin level test (MTA), I get the infamous message "No MX found for your domain. Failed to get AAAA". However, the AAAA is available (and has been for many TTLs).

It was claimed in an earlier topic that all domains should have an MX record, and that there are no RFCs stating the contrary, but actually, not having an MX is valid, according to the RFCs I can find.

In RFC 5321 "Simple Mail Transfer Protocol" Section 5.1 it says:

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

(Note that this RFC makes explicit references to IPv6).

Also, in RFC 3974 "SMTP Operational Experience in Mixed IPv4/v6 Environments" Section 3:

Domains without MX records and failure recovery cases must be handled properly as well.

If NODATA (i.e., empty answer with NOERROR(0) RCODE) is returned, there is no MX record but the name is valid. Assume that there is a record like "name.  IN MX 0 name." (implicit MX)

The IPv6 AAAA record for my mail host is registered with DynDns.org, and they won't add an MX record if it is the same as the A or AAAA record. According to the above RFCs, what they're doing is valid. Shouldn't the HE MTA script be amended to include looking for the AAAA record?

(Note that external mail services such as Gmail can successfully send mail to my host, although this is on IPv4.)

[kasperd]

they won't add an MX record if it is the same as the A or AAAA record.

An MX record must point to a domain name, not to an IP address.

[snarked]

That's not what he said, at least how I read it.

I interpreted him as saying that with:

example.com.  IN  MX   0  example.com.
example.com.  IN  A     192.0.2.1
example.com.  IN  AAAA 2001:DB8::1

the MX record will not be accepted by his DNS provider because it points to its own label (which with the A-RR and/or the AAAA-RR is a host name as well as a domain and zone name).

Technically, his provider is correct.  Labels which have the SOA-RR (zone names) should not be host names.  Host names should be established UNDER zone names.  (Domain names are the registerable zone names.)


If one wants to enable just the domain name as a "host name" valid for HTTP lookups (e.g. to "drop" a leading "www"), the correct way to do that is with a SRV-RR.  I have found that some clients (browsers and robots) will use the SRV record to find the HTTP server (but this is still very rare).  I know this because I do NOT provide address records for my domain names but do have SRV records at the domain name label and programmed my HTTP server to perform redirection should just the domain name be the queried (virtual) host name, and I see such requests (maybe one per day) in my server's request log.

As to whether a domain or host name should always have an MX-RR, granted it is not an absolute requirement but it does provide for better performance.  Without it, the negative MX-RR answer will be cached for what is usually a much shorter time than a positive answer, so many more uncached lookups will occur.  Standard values of 3 hours for negative answers and 1 day for positive answers means that queries for the absent record at a busy destination will cause up to 8 times the DNS traffic as compared to the positive answer frequency.  As a domain name should not have an address-type record because it should not be also a host name, it should then have an MX-RRset (and probably an SRV-RRset too) for its mail service.  Postfix can use the SRV records.  Sendmail will not.

Aside, regarding SRV records:  Many people skip SRV records for DNS itself.  Granted, how can one use the DNS to find the name servers if one doesn't already have the SRV-RRs in hand?  For the DNS service, the SRV records do not indicate a query path as they do for other services, but only the update path; i.e. the SRV-RRs for the domain service should point at only the primary server (or other DNS server) where zone updates are performed.  NS-RRs continue to indicate where queries are directed.

Don't forget:

label.example.com.  IN  MX  0  .

means that there is no mail service at that label (usually a host name for a machine hosting a dedicated service).  That is not the same as:

label.example.com.  IN  MX  0  localhost.
localhost.                IN  A   127.0.0.1
localhost.                IN  AAAA  ::1

where a host does have mail service but only accepts mail from itself.

[kasperd]

I interpreted him as saying that with:

example.com.  IN  MX   0  example.com.
example.com.  IN  A     192.0.2.1
example.com.  IN  AAAA 2001:DB8::1

the MX record will not be accepted by his DNS provider because it points to its own label

That might be what he was trying to say. If this is indeed the reason for the problem, then it can easily be worked around by letting the MX record point to a subdomain and configure that subdomain with the same A and AAAA records as the parent domain.

If one wants to enable just the domain name as a "host name" valid for HTTP lookups (e.g. to "drop" a leading "www"), the correct way to do that is with a SRV-RR.

You'll find that many DNS providers do not support SRV records, but they do support MX records pointing to the domain itself. This may be the case for the majority of DNS providers.

[snarked]

You'll find that many DNS providers do not support SRV records, but they do support MX records pointing to the domain itself. This may be the case for the majority of DNS providers.

Not my problem.  My colocation provider hosts all my domains as secondary name servers (and I run the primary on my box), thus I have every type of RR available to me.