Pourquoi un enregistrement CNAME ne peut-il pas être utilisé au sommet (racine) d'un domaine?

C’est une question canonique sur les CNAME aux sommets (ou racines) des zones

Il est de notoriété publique que les CNAMEenregistrements au sommet d'un domaine sont une pratique tabou.

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

Dans le meilleur des cas, le logiciel du serveur de noms pourrait refuser de charger la configuration et, dans le pire des cas, accepter cette configuration et invalider celle-ci pour example.com.

Récemment, j'ai demandé à une entreprise d’hébergement Web de donner à une unité commerciale les instructions nécessaires pour que CNAME atteigne le sommet de notre domaine. Sachant qu'il s'agirait d'une configuration suicide lorsque BIND serait alimenté, je leur ai dit que nous ne serions pas en mesure de nous conformer et qu'il s'agissait en général de conseils superflus. La société d’hébergement Web a adopté la position selon laquelle les RFC définissant les standards ne l’interdisent pas expressément et que leur logiciel le prend en charge. Si nous ne pouvions pas nommer CNAME l'apex, leur conseil était de ne pas avoir d'enregistrement apex du tout et ils ne fourniraient pas de serveur Web de redirection. ...Quoi?

La plupart d'entre nous savons que RFC1912 insiste sur ce point A CNAME record is not allowed to coexist with any other data., mais soyons honnêtes avec nous-mêmes, cette RFC est uniquement informative. Le plus proche que je connaisse du verbiage qui interdit la pratique est tiré de la RFC1034 :

Si un RR CNAME est présent sur un nœud, aucune autre donnée ne doit être présente; Cela garantit que les données d'un nom canonique et ses alias ne peuvent pas être différents.

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 que c'est assez de corde pour que la plupart des concepteurs de logiciels se pendent. Sachant que tout ce qui serait moins qu'un lien concis avec un slam dunk serait une perte de temps, j'ai fini par laisser la société s'en tirer en reprochant de recommander des configurations qui casseraient les logiciels couramment utilisés sans divulgation appropriée.

Cela nous amène à la période de questions. Pour une fois, j'aimerais que nous devenions vraiment techniques sur la folie des CNAME apex, et que nous ne nous écartions pas de la question comme nous le faisons habituellement lorsque quelqu'un poste sur le sujet. La RFC1912 est interdite, de même que toute autre RFC Informational applicable ici à laquelle je n'ai pas pensé. Fermons ce bébé.

CNAMELes enregistrements ont été créés à l' origine pour permettre à plusieurs noms fournissant la même ressource de créer un alias avec un "nom canonique" unique pour la ressource. Avec l'avènement de l'hébergement virtuel basé sur le nom, il est devenu banal de les utiliser comme une forme générique d'alias d'adresse IP. Malheureusement, la plupart des personnes issues d'un environnement d'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 clairement pas utilisés dans l'identification d'une ressource hôte canonique ( NS, SOA), qui ne peuvent pas être aliasés sans rompre la norme à un niveau fondamental. (particulièrement en ce qui concerne les coupures de zone )

Malheureusement, la norme DNS originale a été rédigée avant que les instances 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 la RFC 2181 pour clarifier plusieurs cas critiques en raison de la formulation vague, et le verbiage mis à jour précise qu'il CNAME est impossible d' utiliser un alias 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 de l'origine de la zone, qui, avec un enregistrement de début d'autorité (SOA), sont les enregistrements obligatoires de chaque zone. Un tel serveur fait autorité pour tous les enregistrements de ressources d'une zone qui ne se trouvent pas dans une autre zone. Les enregistrements NS qui indiquent une zone coupée sont la propriété de la zone enfant créée, de même que tous les autres enregistrements pour l'origine de cette zone enfant ou l'un de ses sous-domaines. Un serveur d'une zone ne doit pas renvoyer de réponses faisant autorité pour les requêtes relatives à des noms dans une autre zone, y compris les enregistrements NS, et peut-être A, d'une zone coupée, à moins qu'il ne s'agisse également d'un serveur pour l'autre zone.

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

La RFC 1034 était assez vague sur les problèmes qui peuvent survenir quand il CNAMEexiste à côté d'autres types d'enregistrements. La RFC 2181 supprime l'ambiguïté et énonce explicitement les types d'enregistrement autorisés à coexister:

10.1. Enregistrements de ressources CNAME

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

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

"nom d'alias" dans ce contexte fait référence à la partie gauche de l' CNAMEenregistrement. La liste à puces indique explicitement que a SOA, NSet les Aenregistrements ne peuvent pas être vus sur un nœud où un CNAMEapparaît également. Lorsque nous combinons à l' article 6.1, il est impossible pour CNAMEexister au sommet comme il aurait à vivre aux côtés obligatoires SOAet NSdossiers.

(Cela semble faire l'affaire, mais si quelqu'un a un chemin de preuve plus court, donnez-lui une chance.)

Mise à jour:

Il semble que la confusion la plus récente provienne de la décision récente de Cloudflare de permettre à un enregistrement CNAME illégal d'être défini au sommet de domaines, pour lequel ils synthétiseront des enregistrements A. Le terme "conforme à la RFC" décrit dans l'article lié indique que les enregistrements synthétisés par Cloudflare fonctionneront bien avec le système DNS. Cela ne change pas le fait qu'il s'agisse d'un comportement complètement personnalisé.

À mon avis, il s’agit d’un mauvais service pour la communauté DNS dans son ensemble: il ne s’agit pas d’un enregistrement CNAME, et il induit les gens en erreur en leur faisant croire que les autres logiciels sont déficients pour ne pas le permettre. (comme le montre ma question)

L'Internet Systems Consortium a récemment publié un article sur CNAME au sommet d'une zone , expliquant les raisons de cette restriction et proposant plusieurs alternatives. Cela ne changera probablement pas de sitôt, malheureusement:

Nous ne pouvons pas changer la façon dont l'enregistrement CNAME spécial est utilisé sans changer toutes les implémentations de serveur> DNS dans le monde en même temps. En effet, sa signification et son interprétation étaient strictement définies dans le protocole DNS; toutes les implémentations DNS et serveur actuelles respectent cette spécification. Si vous essayez d'assouplir l'utilisation de CNAME dans des serveurs faisant autorité sans modifier simultanément tous les résolveurs DNS en cours, la résolution de noms sera interrompue (et les services Web et de messagerie électronique deviendront indisponibles par intermittence pour les organisations qui mettent en œuvre des solutions de serveur faisant autorité "assouplies".

Mais il y a de l'espoir:

Une autre solution potentielle en cours de discussion ajouterait un nouveau type d’enregistrement de ressource DNS que les navigateurs rechercheraient, qui pourrait exister au sommet. Ce serait un nom d’hôte spécifique à l’application pour les requêtes http (similaire à la façon dont fonctionne MX).

Avantages: Ceci est complètement compatible avec la conception du DNS.
Inconvénients: ceci n'est pas encore disponible et nécessiterait une mise à jour du client de navigateur.

Si vous redirigez une zone entière, vous devez utiliser DNAME. Selon RFC 6672 ,

Le RR DNAME et le CNAME RR [RFC1034] provoquent une recherche pour renvoyer (potentiellement) des données correspondant à un nom de domaine différent du nom de domaine demandé. La différence entre les deux enregistrements de ressources est que le RR CNAME dirige la recherche des données chez son propriétaire vers un autre nom unique, alors qu'un RR DNAME dirige les recherches de données sur les descendants du nom de son propriétaire vers des noms correspondants situés sous un nœud différent (unique) de. l'arbre.

Par exemple, parcourez une zone (voir RFC 1034 [RFC1034], Section 4.3.2, étape 3) pour trouver le nom de domaine "foo.example.com", et un enregistrement de ressource DNAME est disponible à "example.com", indiquant que toutes les requêtes sous "exemple.com" soient dirigées vers "exemple.net". Le processus de recherche retournera à l'étape 1 avec le nouveau nom de requête "foo.example.net". Si le nom de la requête avait été "www.foo.example.com", le nouveau nom de la requête serait "www.foo.example.net".