Pourquoi un enregistrement CNAME ne peut-il pas être utilisé à l'apex (aka racine) d'un domaine ?

CNAME les dossiers ont été à l'origine créés pour permettre à plusieurs noms qui fournissent la même ressource d'être aliasés vers un seul "nom canonique" pour la ressource. Avec l'avènement de l'hébergement virtuel par nom, il est devenu courant de les utiliser comme une forme générique d'alias d'adresse IP. Malheureusement, la plupart des personnes qui viennent du monde de l'hébergement web s'attendent à ce que CNAME pour indiquer l'équivalence dans le DNS ce qui n'a jamais été le but recherché. L'apex contient des types d'enregistrements qui sont clairement no utilisé dans l'identification d'une ressource hôte canonique ( NS , SOA ), qui ne peut être aliasé sans rompre la norme à un niveau fondamental. (notamment en ce qui concerne coupures de zones )

Malheureusement, la norme DNS originale a été rédigée avant que les organismes de normalisation ne se rendent compte qu'un verbiage explicite était nécessaire pour définir un comportement cohérent ( RFC 2119 ). Il était nécessaire de créer RFC 2181 afin de clarifier plusieurs cas de figure dus à une formulation vague, et le verbiage mis à jour indique plus clairement qu'une CNAME ne peut pas peut être utilisé pour obtenir un crénelage de l'apex sans enfreindre la norme.

6.1. Autorité de zone

Les serveurs faisant autorité pour une zone sont énumérés dans les enregistrements NS. pour l'origine de la zone, qui, avec un enregistrement Start of Authority (SOA) (SOA), sont les enregistrements obligatoires dans chaque zone. Un tel serveur fait autorité pour tous les enregistrements de ressources dans une zone qui ne sont pas dans une autre zone. Les enregistrements NS qui indiquent une coupure de zone sont la propriété de la zone enfant créée, comme le sont tous les autres enregistrements pour l'élément origine de cette zone enfant, ou de tout sous-domaine de celle-ci. Un serveur pour une zone ne doit pas renvoyer de réponses faisant autorité pour les requêtes liées aux noms de la zone noms d'une autre zone, ce qui inclut les enregistrements NS, et éventuellement A au niveau d'une zone coupée, à moins qu'il ne soit également un serveur pour l'autre zone. zone.

Cela établit que SOA y NS sont obligatoires, mais il ne dit rien sur A ou d'autres types apparaissant ici. Il peut sembler superflu que je le cite alors, mais cela deviendra plus pertinent dans un moment.

RFC 1034 était quelque peu vague quant aux problèmes qui peuvent survenir lorsqu'un CNAME existe aux côtés d'autres types d'enregistrements. RFC 2181 lève l'ambiguïté et énonce explicitement les types d'enregistrements qui sont autorisés à exister à côté d'eux :

10.1. Enregistrements de ressources CNAME

L'enregistrement CNAME (" nom canonique ") du DNS existe pour fournir le nom canonique associé à un nom d'alias. Il ne peut y avoir qu'un seul nom canonique pour un même alias. Ce nom doit généralement être un nom qui existe ailleurs dans le DNS, bien qu'il existe de rares applications d'alias avec applications pour les alias avec le nom canonique correspondant. non défini dans le DNS. Un nom d'alias (étiquette d'un enregistrement CNAME) peut, si le DNSSEC est utilisé, avoir des RR SIG, NXT, et KEY, mais ne peut avoir aucune autres données. C'est-à-dire que pour toute étiquette dans le DNS (tout nom de domaine) exactement l'une des situations suivantes est vraie :

• un enregistrement CNAME existe, accompagné éventuellement de SIG, NXT, et KEY RRs,
• un ou plusieurs enregistrements existent, aucun n'étant un enregistrement CNAME,
• le nom existe, mais n'a pas de RR associé d'aucun type,
• le nom n'existe pas du tout.

Dans ce contexte, le terme "nom d'alias" se réfère à la partie gauche du nom de l'alias. CNAME enregistrement. La liste à puces précise explicitement qu'une SOA , NS y A ne peuvent pas être vus dans un nœud où un CNAME apparaît également. Lorsque nous combinons cela avec la section 6.1, il est impossible qu'une CNAME pour exister à l'apogée, car elle devrait vivre aux côtés de l'obligatoire SOA y NS les dossiers.

(Cela semble faire l'affaire, mais si quelqu'un a un chemin plus court à prouver, merci de le faire).

Mise à jour :

Il semble que la confusion la plus récente vienne de La récente décision de Cloudflare pour permettre de définir un enregistrement CNAME illégal à l'apex des domaines, pour lesquels ils synthétiseront des enregistrements A. Le terme "RFC compliant", tel que décrit dans l'article en question, signifie que les enregistrements synthétisés par Cloudflare seront compatibles avec le DNS. Cela ne change rien au fait qu'il s'agit d'un comportement totalement personnalisé.

À mon avis, c'est un mauvais service rendu à la communauté DNS dans son ensemble : il ne s'agit pas en fait d'un enregistrement CNAME, et cela induit les gens en erreur en leur faisant croire que les autres logiciels sont déficients parce qu'ils ne le permettent pas. (comme le démontre ma question)