Pourquoi un enregistrement CNAME ne peut-il pas être utilisé au sommet (aka racine) d'un domaine?
Ceci est une Question canonique sur les CNAME aux sommets (ou racines) des zones
Il est relativement connu que les enregistrements CNAME 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 pour 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 nouveau dossier. Sachant qu'il s'agirait d'une config suicide pour alimenter BIND, je leur ai dit que nous ne serions pas en mesure de nous conformer et qu'il s'agissait de conseils superflus en général. La société d'hébergement Web a estimé que les RFC définissant la norme ne l'interdisaient pas catégoriquement et que leur logiciel le prend en charge. Si nous ne pouvions pas nommer l'apex, leur conseil était de ne pas avoir d'enregistrement du tout et ils ne fourniraient pas de serveur Web de redirection. ...Quoi?
La plupart d'entre nous savent que RFC1912 insiste pour que A CNAME record is not allowed to coexist with any other data., mais soyons honnêtes avec nous-mêmes ici, que la RFC est uniquement informative. Le plus proche que je connaisse du verbiage qui interdit la pratique est de RFC1034 :
Si un CNAME RR 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 de ses alias ne peuvent pas être différentes.
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 la plupart des concepteurs de logiciels. Sachant que rien de moins qu'un lien concis vers un slam dunk serait une perte de temps, j'ai fini par laisser la société s'en tirer avec des reproches pour recommander des configurations qui pourraient briser les logiciels couramment utilisés sans divulgation appropriée.
Cela nous amène à la Q&A. Pour une fois, j'aimerais que nous obtenions vraiment technique sur la folie des CNAME apex, et ne pas contourner le problème comme nous le faisons habituellement quand quelqu'un publie sur l'objet. RFC1912 est hors limites, comme le sont tous les autres RFC d'information applicables ici auxquels je n'ai pas pensé. Fermons ce bébé.
CNAME les enregistrements ont été à l'origine créés 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 devenu monnaie courante de les utiliser comme forme générique d'alias d'adresse IP. Malheureusement, la plupart des gens qui viennent d'un milieu d'hébergement Web s'attendent à ce que les enregistrements CNAME indiquent l'équivalence dans le DNS, ce qui n'a jamais été l'intention. L'apex contient des types d'enregistrement qui sont clairement pas utilisés dans l'identification d'une ressource hôte canonique (NS, SOA), qui ne peut pas être aliasée sans casser le standard à un niveau fondamental. (en particulier en ce qui concerne coupes de zone )
Malheureusement, la norme DNS d'origine a été écrite avant que les organes directeurs des normes 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 pour clarifier plusieurs cas d'angle en raison d'un libellé vague, et le verbiage mis à jour rend plus clair qu'un CNAME ne peut pas être utilisé pour obtenir l'alias de sommet 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 de début d'autorité (SOA) sont les enregistrements obligatoires dans chaque zone. Un tel serveur fait autorité pour tous les enregistrements de ressources dans une zone qui ne se trouvent pas dans une autre zone. Les enregistrements NS qui indiquent un la coupure de zone est 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 pour une zone ne doit pas renvoyer de réponses faisant autorité pour les requêtes liées aux noms d'une autre zone , qui inclut les enregistrements NS, et peut-être A, lors d'une coupure de zone, sauf s'il s'agit également d'un serveur pour l'autre zone.
Cela établit que les enregistrements SOA et NS sont obligatoires, mais cela ne dit rien sur A ou sur les autres types apparaissant ici. Il peut sembler superflu que je le cite alors, mais cela deviendra plus pertinent dans un instant.
RFC 1034 était quelque peu vague sur les problèmes qui peuvent survenir lorsqu'un CNAME existe aux côtés d'autres types d'enregistrement. RFC 2181 supprime l'ambiguïté et indique explicitement les types d'enregistrement qui peuvent exister à côté d'eux:
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 tel nom canonique pour un seul alias. Ce nom doit généralement être un nom qui existe ailleurs dans le DNS, bien qu'il existe de rares applications pour les alias avec le nom canonique qui l'accompagne 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. Autrement dit, pour toute étiquette du DNS (tout nom de domaine), exactement l'une des affirmations suivantes est vraie:
- un enregistrement CNAME existe, éventuellement accompagné de RR SIG, NXT et KEY,
- un ou plusieurs enregistrements existent, aucun étant des enregistrements CNAME,
- le nom existe, mais n'a aucun RR associé d'aucun type,
- le nom n'existe pas du tout.
"nom d'alias" dans ce contexte fait référence au côté gauche de l'enregistrement CNAME. La liste à puces indique clairement que les enregistrements SOA, NS et A ne peuvent pas être vus sur un nœud où un CNAME apparaît également. Lorsque nous combinons cela avec la section 6.1, il est impossible qu'un CNAME existe au sommet car il devrait cohabiter avec les enregistrements obligatoires SOA et NS.
(Cela semble faire l'affaire, mais si quelqu'un a un chemin plus court vers la preuve, donnez-lui une fissure.)
Mise à jour:
Il semble que la confusion la plus récente vient de décision récente de Cloudflare pour permettre de définir un enregistrement CNAME illégal au sommet des domaines, pour lesquels ils synthétiseront les enregistrements A. "Conforme RFC" comme décrit dans l'article lié fait référence au fait que les enregistrements synthétisés par Cloudflare fonctionneront bien avec DNS. Cela ne change pas le fait qu'il s'agit d'un comportement complètement personnalisé.
À mon avis, cela ne rend pas service à la communauté DNS dans son ensemble: il ne s'agit pas en fait d'un enregistrement CNAME, et il induit les gens en erreur en leur faisant croire que d'autres logiciels sont insuffisants 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. Malheureusement, cela ne devrait pas changer de sitôt:
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 ont été strictement définies dans le protocole DNS; toutes les implémentations actuelles du client et du serveur DNS respectent cette spécification. Tenter de "relâcher" la façon dont CNAME est utilisé dans les serveurs faisant autorité sans changer simultanément tous les résolveurs DNS actuellement en fonctionnement entraînera la rupture de la résolution de noms (et les services Web et de messagerie deviendront indisponibles par intermittence pour les organisations qui mettent en œuvre des solutions de serveur faisant autorité "détendues".
Mais il y a de l'espoir:
Une autre solution potentielle actuellement en 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 MX fonctionne).
Avantages: Ceci est complètement cohérent avec la conception DNS.
Inconvénients: Ce n'est pas encore disponible et nécessiterait une mise à jour du client du navigateur.
Si vous redirigez une zone entière, vous devez utiliser DNAME. Selon RFC 6672 ,
Le DNAME RR 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 interrogé. La différence entre les deux enregistrements de ressources est que le RR CNAME dirige la recherche de données sur son propriétaire vers un autre nom unique, tandis qu'un RR DNAME dirige les recherches de données sur les descendants du nom de son propriétaire vers des noms correspondants sous un nœud (unique) différent de l'arbre.
Par exemple, examinez une zone (voir RFC 1034 [RFC1034], section 4.3.2, étape 3) pour le nom de domaine "foo.example.com", et un enregistrement de ressource DNAME se trouve sur "example.com" indiquant que toutes les requêtes sous "example.com" soient dirigées vers "example.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 était "www.foo.example.com", le nouveau nom de la requête serait "www.foo.example.net".