This recent post by Exchange MVP Bharat Suneja talks about the proper relationship between MX records and CNAME records in DNS. His post kicked off related thoughts on the subject of DNS which come from my years working as a systems administrator at an ISP. At one time I was responsible for the care and feeding of nearly 500 domains, and made my share of mistakes (and saw the corresponding problems that could result).
Bharat correctly points out that RFC 2181, Clarifications to the DNS Specification, prohibit you from pointing an MX record at a CNAME. That is, the following setup is wrong:
@ORIGIN example.invalid.
mxer IN MX 10 cname.example.invalid.
cname IN CNAME host.example.invalid.
host IN A 192.168.0.1
Not only does this cause additional DNS lookups and load, as the RFC (and Bharat) point out, but it can actually cause mail loops with certain software under certain situations. However, this kind of configuration appears to be convenient for admins (which is why it keeps coming back up), because it seems to promise the ease of reduced administration: "If I ever have to change my MX host and I have multiple domains, I just have to change the CNAME record and they're all automatically updated." Too bad it doesn't work this way.
What it needs to look like is this:
@ORIGIN example.invalid.
mxer IN MX 10 host.example.invalid.
cname IN CNAME host.example.invalid.
host IN A 192.168.0.1
If you have multiple MX records to maintain and want to point them to an "alias", then make the "alias" record an additional A record (or corresponding IPv6 record) pointing to the correct IP address:
@ORIGIN example.invalid.
mxer IN MX 10 mail.example.invalid.
mail IN A 192.168.0.1
host IN A 192.168.0.1
"But Devin," I hear some of you say, "This breaks the forward and reverse name mapping for DNS, which you've posted about before!" Well, no. You can easily have multiple PTR resource records for the same domain, just as you can have multiple A records:
@ORIGIN 0.168.192.in-addr.arpa.
1 IN PTR host.example.invalid.
1 IN PTR mail.example.invalid.
This is perfectly valid and will work pretty much all the time these days with modern DNS resolvers and mail servers.
If you're doing frequent host renaming/IP renumbering and worry about keeping your reverse DNS in sync (and you should), then this trick might help, especially if the ISP that handles your reverse IP addresses takes a while to respond to requests:
C:\>dig 148.179.65.64.in-addr.arpa.
; <<>> DiG 9.2.3 <<>> 148.179.65.64.in-addr.arpa.
;; QUESTION SECTION:
;148.179.65.64.in-addr.arpa. IN A
;; ANSWER SECTION:
148.179.65.64.in-addr.arpa. 86400 IN CNAME static-64-65-179-148.rev.3sharp.com.
Instead of having our ISP host a PTR record (thus requiring them to update our hostnames), instead we had them put in CNAME records pointing to a special zone under our control. That zone is what holds the actual PTR records -- allowing us to change both the forward and reverse at the same time.
DNS has a lot of complexity, but at its core it is very simple to understand. I didn't really start grokking DNS until I made a fundamental conceptual leap. Once I made that leap, DNS got a lot easier and I was able to fix a host of common configuration errors that plagued my 500 zonefiles. Since you've read down to this point, I'll share the secret with you:
When you're working with DNS, forget the distinction betweens domains and hosts. There is no "host"; there is only "domain."
As systems admins, we have several types of domains we have to juggle:
- Active Directory domains
- DNS domains
- SMTP domains
- NIS domains (for old-schoool UNIX admins)
- Windows NT domains (for old-school Windows admins)
The convergence of Active Directory with DNS, combined with the reliance of SMTP on DNS, has helped a lot of us blur the lines of distinction between the different types of domains. It's important to remember that even though Active Directory and SMTP both depend on DNS, the domains they describe -- even though they use the same namespace and much of the same terminology -- are different entities. And in DNS, if you forget the concept of a "host", you'll have a much better understanding of how DNS works.
Confused? Well, let me explain it this way: what we tend to think of as a hostname is in reality just another domain. When I take a hostname like mail.3sharp.com and look at it from a DNS perspective, what I really have is a fully-qualified domain name that consists of four separate domains, arranged in a hierarchical order (left to right, most local to most global):
- The most-specific domain, corresponding to what we use as the hostname: mail
- The secondary domain: 3sharp
- The top-level domain (TLD): com
- The root domain: .
The TLD is a sub-domain of the root domain; the secondary domain is a sub-domain of the secondary domain. Within the secondary domain, we have additional sub-domains that are used for multiple purposes, such as the rev sub-domain we use to hold our reverse DNS PTR records, as well as sub-domains that are used to denote hosts. Depending on how we use these sub-domains, we can use different types of DNS resource records, some of which are mutually exclusive:
- Domains which are themselves going to have sub-domains need to have a namesrever (NS) recordset[1] defined. This helps support the proper DNS delegation behavior and allows us to split up our DNS zone file on domain boundaries, if needed.
- Domains which are aliases to other domains have a CNAME recordset. No other record types are allowed for these domains; the CNAME is an absolute referral mechanism that instructs the resolver to use the information found in the specified domain without reservation or reference to the domain the CNAME record is part of.[2] Note that this means you can't have a domain that has both NS and CNAME recordsets; you're either delegating the domain or aliasing it.
- Domains which are hosts have the A recordset.
- Domains for which mail exchange is a consideration have the MX recordset.
- Domains which represent a reverse DNS mapping have the PTR recordset.
These aren't the only kinds of records available, of course, but they're the most common ones.
I know this post has covered a lot of ground quickly, but I hope you've walked away with something that made you say "Aha! That makes this make sense!" If you have any questions or need further clarification, please send me an email.
[1] A recordset is a collection of one or more resource records of the same type. Some record types only allow a single record in the recordset, but others such as A, PTR, and MX allow multiple records to be defined.
[2] This, BTW, is the true technical reasons why you break things by pointing MX records at CNAME records; according to DNS, a CNAME points you to a different domain, which could be in a different zone file, under the control of some other nameserver or admin. It is the responsibility of the domain admin to designate MX hosts for their own domains, and by pointing an MX record to a CNAME you're effectively trying to override that mechanism.