153

This is a Canonical Question about CNAMEs at the apices (or roots) of zones

It's relatively common knowledge that CNAME records at the apex of a domain are a taboo practice.

Example: example.com. IN CNAME ithurts.example.net.

In a best case scenario nameserver software might refuse to load the configuration, and in the worst case it might accept this configuration and invalidate the configuration for example.com.

Recently I had a webhosting company pass instructions to a business unit that we needed to CNAME the apex of our domain to a new record. Knowing that this would be a suicide config when fed to BIND, I advised them that we would not be able to comply and that this was bunk advice in general. The webhosting company took the stance that it is not outright forbidden by standard defining RFCs and that their software supports it. If we could not CNAME the apex, their advice was to have no apex record at all and they would not provide a redirecting webserver. ...What?

Most of us know that RFC1912 insists that A CNAME record is not allowed to coexist with any other data., but let's be honest with ourselves here, that RFC is only Informational. The closest I know to verbiage that forbids the practice is from RFC1034:

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

Unfortunately I've been in the industry long enough to know that "should not" is not the same as "must not", and that's enough rope for most software designers to hang themselves with. Knowing that anything short of a concise link to a slam dunk would be a waste of my time, I ended up letting the company get away with a scolding for recommending configurations that could break commonly used software without proper disclosure.

This brings us to the Q&A. For once I'd like us to get really technical about the insanity of apex CNAMEs, and not skirt around the issue like we usually do when someone posts on the subject. RFC1912 is off limits, as are any other Informational RFC applicable here that I didn't think of. Let's shut this baby down.

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • 1
    RFC 1034 does predate RFC 2119 by quite a bit of time and experience. – Michael Hampton Jul 19 '14 at 14:06
  • Adobe AEM CMS system, requires users to setup CNAME for their domains with a value of cdn.adobeaemcloud.com. This works for www.yourname.com, but then how do you setup yourdomain.com to also point to your very expensive enterprise CMS if apex CNAMES are not allowed by your DNS provider? You can find a current IP, and create an A record for your apex domain, but this might change. How do people handle this? – eos Sep 21 '21 at 14:25

3 Answers3

120

CNAME records were originally created to allow multiple names that provide the same resource to be aliased to a single "canonical name" for the resource. With the advent of name based virtual hosting, it has instead become commonplace to use them as a generic form of IP address aliasing. Unfortunately, most people who come from a web hosting background expect CNAME records to indicate equivalence in the DNS, which has never been the intent. The apex contains record types which are clearly not used in the identification of a canonical host resource (NS, SOA), which cannot be aliased without breaking the standard at a fundamental level. (particularly in regards to zone cuts)

Unfortunately, the original DNS standard was written before the standards governing bodies realized that explicit verbiage was necessary to define consistent behavior (RFC 2119). It was necessary to create RFC 2181 to clarify several corner cases due to vague wording, and the updated verbiage makes it clearer that a CNAME cannot be used to achieve apex aliasing without breaking the standard.

6.1. Zone authority

The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone. Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone.

This establishes that SOA and NS records are mandatory, but it says nothing about A or other types appearing here. It may seem superfluous that I quote this then, but it will become more relevant in a moment.

RFC 1034 was somewhat vague about the problems that can arise when a CNAME exists alongside other record types. RFC 2181 removes the ambiguity and explicitly states the record types that are allowed to exist alongside them:

10.1. CNAME resource records

The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name. There may be only one such canonical name for any one alias. That name should generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases with the accompanying canonical name undefined in the DNS. An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data. That is, for any label in the DNS (any domain name) exactly one of the following is true:

  • one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
  • one or more records exist, none being CNAME records,
  • the name exists, but has no associated RRs of any type,
  • the name does not exist at all.

"alias name" in this context is referring to the left hand side of the CNAME record. The bulleted list makes it explicitly clear that a SOA, NS, and A records cannot be seen at a node where a CNAME also appears. When we combine this with section 6.1, it is impossible for a CNAME to exist at the apex as it would have to live alongside mandatory SOA and NS records.

(This seems to do the job, but if someone has a shorter path to proof please give a crack at it.)

Update:

It seems that the more recent confusion is coming from Cloudflare's recent decision to allow an illegal CNAME record to be defined at the apex of domains, for which they will synthesize A records. "RFC compliant" as described by the linked article refers to the fact that the records synthesized by Cloudflare will play nicely with DNS. This does not change the fact that it is a completely custom behavior.

In my opinion this is a disservice to the larger DNS community: it is not in fact a CNAME record, and it misleads people into believing that other software is deficient for not allowing it. (as my question demonstrates)

Community
  • 1
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • 11
    I agree with this proof and I don't think this two step path of proof is particularly long or convoluted. (1. the zone apex is guaranteed to have at least `SOA` + `NS` records, 2. `CNAME` records are not allowed to coexist with other data) – Håkan Lindqvist Jul 19 '14 at 11:19
  • 3
    Overall, I think it's a very good explanation. If anything could be added, I think it would possibly be further explaining what a `CNAME` record actually means, as that is probably the most widely misunderstood record type. Even though that is kind of beyond the point, I think this being a FAQ is a direct result of many (most?) not having a proper understanding of `CNAME`. – Håkan Lindqvist Jul 19 '14 at 11:23
  • @HåkanLindqvist Agreed! I am actually starting to get very angry at people who grossly misunderstand what CNAME is and isnt. Like people not grasping that CNAME != HTTP redirect. 0_o – Joe Sniderman Sep 06 '14 at 23:22
  • 2
    OK it's illegal but does it make sense? Why does a domain with a CNAME need NS and SOA records? And if it does, why can't it have them? – Denis Howe May 04 '15 at 21:18
  • 2
    @Denis That can't be comprehensively answered within a comment. The shortest answer is that you need to read the RFCs (1034, 1035) and have a good understanding of what referrals are, what the required behaviors for a referral are (AUTHORITY, SOA record presence, etc.), and why this type of "referral-less" aliasing violates many expectations of DNS servers at the functional level. And that's just to start with. That question isn't a good topic for here because it's speculative and not rooted in a problem that you would encounter working with a properly designed, standards compliant DNS server. – Andrew B May 04 '15 at 23:13
  • 2
    @DenisHowe in brief: there is no such thing as "a domain" without NS and SOA records. those are the non-optional records. – hakamadare Jul 22 '15 at 19:42
  • 1
    This whole no-CNAME-at-apex rule throws a huge spanner in the works of the "no-www" movement. Let's face it, HTTP has far more exposure than DNS, and the DNS implementations' refusal just makes HTTP folks look for workarounds. – Ekevoo Sep 30 '15 at 17:23
  • That said, this question was immensely helpful - I now finally understand why I can't (it's not just an implementation bug of the particular version of bind I was using). I can now plan accordingly, so that my DNS rules can fulfull my HTTP needs. – Ekevoo Sep 30 '15 at 17:25
  • 8
    @Ekevoo One can argue the HTTP implementations ought to have adopted `SRV` instead, that would also have made this a non-issue. The problem is not limited to what is discussed here; `CNAME` is, contrary to popular belief, not a great match for what is needed. In the end, as `CNAME` does not work like people expect(!) and can't be redesigned retroactively and as HTTP implementations do not use `SRV` it seems more likely that the "alias" style functionality becomes more prevalent to cater to HTTP (record type specific aliasing implemented behind the scenes rather than as a visible record type) – Håkan Lindqvist Oct 30 '15 at 14:41
  • 2
    @HåkanLindqvist Good points. Switching to `SRV` is not as impossible to change as it seems, though. The first step is adding support for browsers, the second step is major websites (Facebook, Google, etc.) supporting it, the third step is start to add warnings to browsers. That all would take some good 5 to 15 years, but it's pretty feasible. – Ekevoo Nov 02 '15 at 16:14
  • @HåkanLindqvist regarding your wish for an explanation about what a `CNAME` is, I've proposed a clarification edit of the whole question that includes your wish. I hope these changes allow different audience to understand the danger and not shoot themselves in the foot. – Stéphane Gourichon Jan 21 '16 at 11:01
  • In hindsight, I decided that the edit was a little too much on the meandering side and rolled it back. It's a little much to preface this with a full introduction. Instead, I've chosen to take the advice of @Håkan (which I originally misread) and elaborated on the CNAME fallacy. Håkan, please review the current answer and improve upon it where you see fit. – Andrew B Apr 11 '16 at 19:50
  • 1
    The four-step proof would be improved by a footnote or hyperlink that explained the difference between options 3 and 4: "the name exists, but has no associated RRs of any type" and "the name does not exist at all." Personally I think I understand the difference in terms of server responses, but I don't understand why option 3 would be useful or where we'd encounter it. Again, this is off-topic for the actual question asked, but a hyperlink to more information on each option would be a great addition to this answer. – Quuxplusone Dec 27 '17 at 20:54
  • 2
    @Quuxplusone It's a rabbit hole as far as this particular topic is concerned; useful to know for technical reasons, but not having much bearing on the topic being discussed. If you wish to learn further, the concept for case #3 is known as "NODATA" and is discussed in [RFC 2308](https://tools.ietf.org/html/rfc2308) (Negative Caching). The nuance is the difference between telling a client "nothing exists with that name" vs. "that name exists but not with the record type you requested". The former can potentially be used to skip future queries, but is not supported very well. (it's complicated) – Andrew B Jan 02 '18 at 15:48
8

June 2022 Update

New SVCB and HTTPS resource records enable aliasing of apex domains and facilitate lookups for connecting to services like HTTP origins. Many DNS providers and browsers already support them, so it seems this will be the de facto standard one the spec is finalized.

Resources

The Internet Systems Consortium recently posted a write-up on CNAME at the apex of a zone, why this restriction exists, and a number of alternatives. This is not likely to change anytime soon, sadly:

We cannot change how the special CNAME record is used without changing all of the >DNS server implementations in the world at the same time. This is because its meaning and interpretation was strictly defined in the DNS protocol; all current DNS client and server implementations adhere to this specification. Attempting to ‘relax’ how CNAME is used in authoritative servers without simultaneously changing all DNS resolvers currently in operation will cause name resolution to break (and web and email services to become intermittently unavailable for those organizations implementing ‘relaxed’ authoritative server solutions.

But there's hope:

Another potential solution currently being discussed would add a new dns resource record type that browsers would look up, that could exist at the apex. This would be an application-specific hostname for http requests (similar to the way MX works).

Pros: This is completely consistent with the DNS design.
Cons: This is not available yet, and would require a browser client update.

Daniel Liuzzi
  • 181
  • 1
  • 4
  • 7
    "Hope"? There already was a "solution", i.e. HTTP SRV records, but these were universally rejected. What's not clear is what the "problem" is. – Michael Hampton Dec 31 '18 at 05:32
  • 1
    I wasn't even aware of HTTP SRV so I have no clue why it was rejected. _Hopefully_ this potential new solution sees better reception whenever/if it comes out. – Daniel Liuzzi Dec 31 '18 at 16:23
1

If you are redirecting an entire zone, you should use DNAME. According to RFC 6672,

The DNAME RR and the CNAME RR [RFC1034] cause a lookup to (potentially) return data corresponding to a domain name different from the queried domain name. The difference between the two resource records is that the CNAME RR directs the lookup of data at its owner to another single name, whereas a DNAME RR directs lookups for data at descendants of its owner's name to corresponding names under a different (single) node of the tree.

For example, take looking through a zone (see RFC 1034 [RFC1034], Section 4.3.2, step 3) for the domain name "foo.example.com", and a DNAME resource record is found at "example.com" indicating that all queries under "example.com" be directed to "example.net". The lookup process will return to step 1 with the new query name of "foo.example.net". Had the query name been "www.foo.example.com", the new query name would be "www.foo.example.net".

Community
  • 1
Brian Minton
  • 256
  • 7
  • 15
  • 4
    This is an incorrect interpretation. Refer to the second line of the table in [RFC 6672 §2.2](https://tools.ietf.org/html/rfc6672#section-2.2). An apex DNAME will result in no match for query types other than DNAME at the apex, i.e. does not result in an actual aliasing of an apex A or AAAA record. – Andrew B Mar 27 '17 at 17:17
  • An apex DNAME will result in no *redirection* for queries of the apex name. It's not technically correct to say that it'll result in no *match*. You'll still get a match if you query for NS, SOA, or any other RR types that are actually *present* for the apex name. From [RFC 6672](https://tools.ietf.org/html/rfc6672#section-2.3): "If a DNAME record is present at the zone apex, there is still a need to have the customary SOA and NS resource records there as well. Such a DNAME cannot be used to **mirror** a zone completely, as it does not **mirror** the zone apex." – Quuxplusone Dec 27 '17 at 21:16