As you can see from the above query, the record mx1.somedomain.com is not resolved to an IP address. This is because it’s a CNAME.

To resolve the CNAME, the sender’s DNS server will have to perform a second query.

Not only is that inefficient, it is in fact explicitly prohibited by RFC 2181.

Section 10.3 of RFC 2181 states:

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

Searching for either NS or MX records causes “additional section processing” in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made.

Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias. Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query.

I’ve always assumed not pointing MX records to CNAME record(s) is merely a best practice or recommendation, and not a requirement. I stand corrected, as DNS geek (Zenprise seems to have more than its fair share of these :) Dmitri pointed out.

Bharat, thanks for posting this. I’ve been meaning to put together a post on DNS configuration issues, and your post sparked mine. Since the trackbacks don’t seem to be working, here’s the link: DNS gotchas and tips.

The irony there is that none of the domains I queried (including rfc-editor.org and ietf.org) follow the rfc standard. Every domain I queried (there were about 50) pointed their MX records to a CNAME, which was then resolved directly to an IP address.

Quote:As opposed to RFC 2181, there is a newer RFC that already allows the use of CNAME.

RFC 2821 section 2.3.5 cites:

“Domain names are used as names of hosts and of other entities in the domain name hierarchy. For example, a domain may refer to an alias (label of a CNAME RR) or the label of Mail exchanger records to be used to deliver mail instead of representing a host name.”

Section 5 also mentions the following:

“Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name.”

Even though current RFCs support CNAMEs for MX records, the RFCs aren’t necessarily followed. Older or infrequently supported mail servers may not know how to properly resolve a CNAME MX and cause hard-to-detect mail delivery issues. Only older and obsolete DNS software may encounter this issue.

Anonymous is mistaken. The quote from section 2.3.5 of RFC 2821 is defining what a domain is for the purpose of that RFC, not stating that an MX record can resolve to a CNAME. And section 5 of that same RFC states that:

The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name.

Note the word instead therein. The MX look-up must either return a MX record, or not. If not, there must be either a CNAME or an A record.

Where an MX record exists, it is used. Thus section 5 does not address or change behavior of what the MX record resolves to. (i.e. RFC 2181 requirements still apply, namely that the MX must point to an A record).

Correct…. so for example, Windows allows you to enter a FQDN for your MX record
MX.SOMEDOMAIN.COM
Then MX.SOMEDOMAIN.COM must also have an A record (instead of a CNAME) pointing to the specific IP address…. Essentially an MX record is a special kind of CNAME record specifically for mail exchange…. You wouldn’t have a CNAME point to another CNAME….. So when a server queries for the MX record, it is actually doing two DNS queries… one for the MX FQDN, and a second for the A record…. if you use a CNAME for the MX record, then it increases to 3 inquiries…. 1 for the MX FQDN, 2 for the CNAME, and 3 for the final underlying A record.