Though the practice of pointing MX records to CNAME (alias) records is not that uncommon, it certainly isn’t in keeping with internet standards.
When you point a MX record to a CNAME, you’re in fact inviting double the DNS traffic to your DNS servers. Try this by performing a name resolution query using nslookup:
>nslookup -querytype=MX somedomain.com
somedomain.com MX preference = 5, mail exchanger = mx1.somedomain.com
somedomain.com MX preference = 10, mail exchanger = mx2.somedomain.com
mx2.somedomain.com internet address = 64.31.212.21
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.
{ 9 comments… read them below or add one }
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.
that has since been fixed.
jasen@sekhmet:~$ host rfc-editor.org
rfc-editor.org has address 4.31.198.49
rfc-editor.org has IPv6 address 2001:1900:3001:11::31
rfc-editor.org mail is handled by 0 rfc-editor.org.
jasen@sekhmet:~$ host ietf.org
ietf.org has address 4.31.198.44
ietf.org has IPv6 address 2001:1900:3001:11::2c
ietf.org mail is handled by 0 mail.ietf.org.
jasen@sekhmet:~$ host mail.ietf.org.
mail.ietf.org has address 4.31.198.44
mail.ietf.org has IPv6 address 2001:1900:3001:11::2c
Actually this is now allowed according to RFC 2821. See the following URL: http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id;=EN-1035667
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.
End quote.
No.
CNAMEs can indicate the domain to look in to find the MX record.
MX records are not allowed to indicate CNAME records.
https://tools.ietf.org/html/rfc5321#section-5.1
paragraph 4 MX resource records must indicate names that resolve to
AAAA or A records,
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).
This is strange to me; as Windows DNS only allows to to enter a FQDN not an IP
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.
a DNS server may return both the MX and the relevant A or AAAA records in response to the initial MX query. (especially when they are in the same zone)