>
Ceci est a [Canonical Question](http://meta.serverfault.com/questions/1986) about CNAMEs at le apices (or roots) of zones
C'est relatively common knowledge that `CNAME` records at le 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 le configuration, et in le worst case it might accept this configuration et invalidate le configuration par exemple.com.
Recently I had a webhosting company pass instructions to a business unit that we needed to CNAME le apex of our domain to a nouveau record. Knowing that this would be a suicide config quand fed to BIND, I advised them that we would pas be able to comply et that this was bunk advice in general. The webhosting company took le stance that it is pas outright forbidden by standard defining RFCs et that *their* software supports it. If we could pas CNAME le apex, leur advice was to have no apex record at tous et they would pas provide a redirecting webserver. ...What?
Most of us know that [RFC1912](https://www.rfc-editor.org/rfc/rfc1912) insists that `A CNAME record is not allowed to coexist with any other data.`, mais let's be honest avec ourselves here, that RFC is seulement Informational. The closest Je sais to verbiage that forbids le practice is depuis [RFC1034](https://www.rfc-editor.org/rfc/rfc1034):
>
If a CNAME RR is present at a node, no autre data should be
present; this ensures that le data for a canonical name et its aliases
cannot be different.
Unfortunately J'ai been in le industry long enough to know that "should not" is pas le même as "must not", et c'est enough rope for le plus software designers to hang themselves with. Knowing that anything short of a concise link to a slam dunk would be a waste of mon time, I ended up letting le company get away avec a scolding for recommending configurations that could break commonly used software sans proper disclosure.
This brings us to le Q&A. For once J'aimerais like us to get *really* technical about le insanity of apex CNAMEs, et pas skirt around le issue like we usually do quand someone posts on le subject. [RFC1912](https://www.rfc-editor.org/rfc/rfc1912) is off limits, as are tout autre Informational RFC applicable here that Je n'ai pas think of. Let's shut this baby down.
Pourquoi un enregistrement CNAME ne peut-il pas être utilisé à l'apex (racine) d'un domaine ?
Re: Pourquoi un enregistrement CNAME ne peut-il pas être utilisé à l'apex (racine) d'un domaine ?
`CNAME` records were [originally](https://www.rfc-editor.org/rfc/rfc1034#section-3.6.2) created to allow multiple names that provide le même resource to be aliased to a single "canonical name" for le resource. With le advent of name based virtual hosting, it has à la place become commonplace to use them as a generic form of IP address aliasing. Malheureusement, le plus people who come depuis a web hosting background expect `CNAME` records to indicate *equivalence in le DNS*, qui has jamais been le intent. The apex contains record types qui are clearly *not* used in le identification of a canonical host resource (`NS`, `SOA`), qui cannot be aliased sans breaking le standard at a fundamental level. (particularly in regards to [zone cuts](https://www.rfc-editor.org/rfc/rfc2181#section-6))
Malheureusement, le original DNS standard was written avant le standards governing bodies realized that explicit verbiage was nécessaire to define consistent behavior ([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119)). C'était nécessaire to create [RFC 2181](https://www.rfc-editor.org/rfc/rfc2181) to clarify plusieurs corner cases due to vague wording, et le updated verbiage makes it clearer that a `CNAME` *cannot* be used to achieve apex aliasing sans breaking le standard.
>
6.1. Zone authority
**The authoritative servers for a zone are enumerated in le NS records
for le origin of le zone, which, along avec a Start of Authority
(SOA) record are le mandatory records in chaque zone.** Such a server
is authoritative for tous resource records in a zone that are pas in
another zone. The NS records that indicate a zone cut are the
property of le child zone created, as are tout autre records for the
origin of that child zone, ou tout sub-domains of it. A server for a
zone should pas return authoritative answers for queries related to
names in another zone, qui includes le NS, et perhaps A, records
at a zone cut, sauf si it aussi happens to be a server for le other
zone.
This establishes that `SOA` et `NS` records are mandatory, mais it says nothing about `A` ou autre types appearing here. It may seem superfluous that I quote this then, mais it will become more relevant in a moment.
[RFC 1034](https://www.rfc-editor.org/rfc/rfc1034) was somewhat vague about le problems that can arise quand a `CNAME` exists alongside autre record types. [RFC 2181](https://www.rfc-editor.org/rfc/rfc2181) removes le ambiguity et explicitly states le 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 avec an alias name. There may be seulement one
such canonical name for tout one alias. That name should generally be
a name that exists elsewhere in le DNS, bien que there are certains rare
applications for aliases avec le accompanying canonical name
undefined in le DNS. **An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, et KEY RRs, mais may have no
other data.** That is, for tout label in le DNS (any domain name)
exactly one of le suivant is true:
- one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
- one ou more records exist, none being CNAME records,
- le name exists, mais has no associated RRs of tout type,
- le name does pas exist at all.
"alias name" in this context is referring to le left hand side of le `CNAME` record. The bulleted list makes it explicitly clear that a `SOA`, `NS`, et `A` records cannot be seen at a node où a `CNAME` aussi appears. When we combine this avec section 6.1, it is impossible for a `CNAME` to exist at le apex as it would have to live alongside mandatory `SOA` et `NS` records.
(This seems to do le job, mais si someone has a shorter path to proof please give a crack at it.)
Update:
It seems that le more recent confusion is coming depuis [Cloudflare's recent decision](https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root) to allow an illegal CNAME record to be defined at le apex of domains, for qui they will synthesize A records. "RFC compliant" as described by le linked article refers to le fact that le records synthesized by Cloudflare will play nicely avec DNS. This does pas changez le fact that it is a completely custom behavior.
In mon opinion this is a disservice to le larger DNS community: it is pas in fact a CNAME record, et it misleads people into believing that autre software is deficient for pas allowing it. (as mon question demonstrates)
Malheureusement, le original DNS standard was written avant le standards governing bodies realized that explicit verbiage was nécessaire to define consistent behavior ([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119)). C'était nécessaire to create [RFC 2181](https://www.rfc-editor.org/rfc/rfc2181) to clarify plusieurs corner cases due to vague wording, et le updated verbiage makes it clearer that a `CNAME` *cannot* be used to achieve apex aliasing sans breaking le standard.
>
6.1. Zone authority
**The authoritative servers for a zone are enumerated in le NS records
for le origin of le zone, which, along avec a Start of Authority
(SOA) record are le mandatory records in chaque zone.** Such a server
is authoritative for tous resource records in a zone that are pas in
another zone. The NS records that indicate a zone cut are the
property of le child zone created, as are tout autre records for the
origin of that child zone, ou tout sub-domains of it. A server for a
zone should pas return authoritative answers for queries related to
names in another zone, qui includes le NS, et perhaps A, records
at a zone cut, sauf si it aussi happens to be a server for le other
zone.
This establishes that `SOA` et `NS` records are mandatory, mais it says nothing about `A` ou autre types appearing here. It may seem superfluous that I quote this then, mais it will become more relevant in a moment.
[RFC 1034](https://www.rfc-editor.org/rfc/rfc1034) was somewhat vague about le problems that can arise quand a `CNAME` exists alongside autre record types. [RFC 2181](https://www.rfc-editor.org/rfc/rfc2181) removes le ambiguity et explicitly states le 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 avec an alias name. There may be seulement one
such canonical name for tout one alias. That name should generally be
a name that exists elsewhere in le DNS, bien que there are certains rare
applications for aliases avec le accompanying canonical name
undefined in le DNS. **An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, et KEY RRs, mais may have no
other data.** That is, for tout label in le DNS (any domain name)
exactly one of le suivant is true:
- one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
- one ou more records exist, none being CNAME records,
- le name exists, mais has no associated RRs of tout type,
- le name does pas exist at all.
"alias name" in this context is referring to le left hand side of le `CNAME` record. The bulleted list makes it explicitly clear that a `SOA`, `NS`, et `A` records cannot be seen at a node où a `CNAME` aussi appears. When we combine this avec section 6.1, it is impossible for a `CNAME` to exist at le apex as it would have to live alongside mandatory `SOA` et `NS` records.
(This seems to do le job, mais si someone has a shorter path to proof please give a crack at it.)
Update:
It seems that le more recent confusion is coming depuis [Cloudflare's recent decision](https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root) to allow an illegal CNAME record to be defined at le apex of domains, for qui they will synthesize A records. "RFC compliant" as described by le linked article refers to le fact that le records synthesized by Cloudflare will play nicely avec DNS. This does pas changez le fact that it is a completely custom behavior.
In mon opinion this is a disservice to le larger DNS community: it is pas in fact a CNAME record, et it misleads people into believing that autre software is deficient for pas allowing it. (as mon question demonstrates)