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

Il est relativement connu que les CNAMEenregistrements au sommet d'un domaine sont une pratique taboue.

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

Dans le meilleur des cas, le logiciel de serveur de noms peut refuser de charger la configuration, et dans le pire des cas, il peut accepter cette configuration et invalider la configuration de example.com.

Récemment, j'ai demandé à une société d'hébergement Web de transmettre des instructions à une unité commerciale dont nous avions besoin pour CNAME le sommet de notre domaine vers un nouvel enregistrement. Sachant que ce serait une configuration suicide lorsqu'elle serait transmise à BIND, je leur ai dit que nous ne serions pas en mesure de nous conformer et que c'était un conseil fou en général. La société d'hébergement Web a pris la position que ce n'est pas purement et simplement interdit par les RFC définissant des normes et que leur logiciel le prend en charge. Si nous ne pouvions pas CNAME l'apex, leur conseil était de n'avoir aucun enregistrement d'apex et ils ne fourniraient pas de serveur Web de redirection. ...Quoi?

La plupart d'entre nous savent que la RFC1912 insiste sur le fait que A CNAME record is not allowed to coexist with any other data., mais soyons honnêtes avec nous-mêmes ici, la RFC est uniquement informative. Le plus proche que je connaisse du verbiage qui interdit la pratique est de la 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.

Malheureusement, je suis dans l'industrie depuis assez longtemps pour savoir que "ne devrait pas" n'est pas la même chose que "ne doit pas", et c'est assez de corde pour que la plupart des concepteurs de logiciels se pendent. Sachant que tout ce qui n'était pas un lien concis vers un slam dunk serait une perte de temps, j'ai fini par laisser l'entreprise s'en tirer avec une réprimande pour avoir recommandé des configurations qui pourraient casser les logiciels couramment utilisés sans divulgation appropriée.

Cela nous amène aux questions-réponses. Pour une fois, j'aimerais que nous soyons vraiment techniques sur la folie des CNAME apex, et que nous ne contournions pas le problème comme nous le faisons habituellement lorsque quelqu'un publie sur le sujet. La RFC1912 est interdite, tout comme toute autre RFC d'information applicable ici à laquelle je n'ai pas pensé. Fermons ce bébé.

answer

CNAMELes enregistrements ont été créés à l' origine pour permettre à plusieurs noms qui fournissent la même ressource d'être aliasés en un seul « nom canonique » pour la ressource. Avec l'avènement de l'hébergement virtuel basé sur le nom, il est plutôt devenu courant de les utiliser comme forme générique d'alias d'adresse IP. Malheureusement, la plupart des gens qui viennent du milieu de l'hébergement Web s'attendent CNAMEà ce que les enregistrements indiquent une équivalence dans le DNS , ce qui n'a jamais été l'intention. L'apex contient des types d'enregistrement qui ne sont manifestement pas utilisés dans l'identification d'une ressource hôte canonique ( NS, SOA), qui ne peut pas être aliasée sans enfreindre la norme à un niveau fondamental. (notamment en ce qui concerne les coupes de zone )

Malheureusement, la norme DNS originale a été écrite avant que les organismes de réglementation des normes ne réalisent qu'un verbiage explicite était nécessaire pour définir un comportement cohérent ( RFC 2119 ). Il était nécessaire de créer la RFC 2181 pour clarifier plusieurs cas de coin en raison d'une formulation vague, et le verbiage mis à jour indique plus clairement qu'un CNAME ne peut pas être utilisé pour obtenir un alias apex sans enfreindre la norme.

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.

Cela établit cela SOAet les NSenregistrements sont obligatoires, mais cela ne dit rien sur Aou d'autres types apparaissant ici. Il peut sembler superflu que je cite cela alors, mais cela deviendra plus pertinent dans un instant.

La RFC 1034 était quelque peu vague sur les problèmes qui peuvent survenir lorsqu'un CNAMEexiste à côté d'autres types d'enregistrements. RFC 2181 supprime l'ambiguïté et indique explicitement les types d'enregistrement qui sont autorisés à exister à côté d'eux :

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.

« nom d'alias » dans ce contexte fait référence à la partie gauche de l' CNAMEenregistrement. La liste à puces indique clairement qu'un SOA, NS, et les Aenregistrements ne peuvent pas être vus à un nœud où un CNAMEapparaît également. Lorsque nous combinons cela avec la section 6.1, il est impossible pour a CNAMEd'exister au sommet car il devrait cohabiter avec obligatoire SOAet NSrecords.

(Cela semble faire le travail, mais si quelqu'un a un chemin plus court vers la preuve, veuillez essayer.)


Mettre à jour:

Il semble que la confusion la plus récente vienne de la récente décision de Cloudflare d'autoriser la définition d'un enregistrement CNAME illégal au sommet des domaines, pour lesquels ils synthétiseront les enregistrements A. « Conforme aux RFC » tel que décrit par l'article lié fait référence au fait que les enregistrements synthétisés par Cloudflare fonctionneront bien avec DNS. Cela ne change rien au fait qu'il s'agit d'un comportement complètement personnalisé.

À mon avis, cela ne rend pas service à la communauté DNS dans son ensemble : ce n'est en fait pas un enregistrement CNAME, et cela induit les gens en erreur en leur faisant croire que d'autres logiciels sont déficients pour ne pas le permettre. (comme ma question le démontre)

L'Internet Systems Consortium a récemment publié un article sur CNAME au sommet d'une zone , pourquoi cette restriction existe et un certain nombre d'alternatives. Cela ne devrait pas changer de sitôt, malheureusement :

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.

Mais il y a de l'espoir :

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.

Si vous redirigez une zone entière, vous devez utiliser DNAME. Selon la 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".