• 1. London, UK
  • 2. New York, NY
  • 3. Sydney, Australia
  • 4. Melbourne, Australia
  • 5. Moscow, Russia
  • 6. Singapore
  • 7. Paris, France
  • 8. Chicago, IL
  • 9. Hong Kong
  • 10. Houston, TX

Tuesday, December 05, 2006

 

Should MX record point to CNAME records (aliases)?

Posted by Bharat Suneja at 6:32 PM
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.

Labels: ,

5 Comments:

December 7, 2006 11:58 AM
Anonymous Devin L. Ganger said...

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.

 
December 15, 2006 2:47 PM
Blogger Jacob said...

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.

 
December 11, 2007 5:16 PM
Anonymous Anonymous said...

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.

 
January 30, 2008 1:07 PM
Anonymous Astounding said...

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).

 
November 23, 2008 7:32 PM
Anonymous Anonymous said...

This is strange to me; as Windows DNS only allows to to enter a FQDN not an IP

 

Post a Comment

Links to this post:

Create a Link

<< Home