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


117

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é.


1
La RFC 1034 est antérieure à la RFC 2119 avec beaucoup de temps et d'expérience.
Michael Hampton

Réponses:


94

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)


8
Je suis d’accord avec cette preuve et je ne pense pas que ce processus de preuve en deux étapes soit particulièrement long ou compliqué. (1. il est garanti que le sommet de la zone a au moins SOA+ NSenregistrements, 2. les CNAMEenregistrements ne sont pas autorisés à coexister avec d'autres données)
Håkan Lindqvist le

2
Globalement, je pense que c'est une très bonne explication. Si quelque chose pouvait être ajouté, je pense que cela expliquerait peut-être davantage ce que CNAMEsignifie réellement un enregistrement, car il s'agit probablement du type d'enregistrement le plus mal compris. Même si cela dépasse le propos, je pense que le fait d'être une FAQ est le résultat direct du fait que beaucoup (la plupart?) Ne comprennent pas correctement CNAME.
Håkan Lindqvist le

2
OK c'est illégal mais est-ce logique? Pourquoi un domaine avec un CNAME a-t-il besoin d'enregistrements NS et SOA? Et si c'est le cas, pourquoi ne peut-il pas les avoir?
Denis Howe

2
@ Denis Il ne peut pas être répondu de manière complète dans un commentaire. La réponse la plus courte est que vous devez lire les RFC (1034, 1035) et bien comprendre ce que sont les références, les comportements requis pour une référence (AUTORITÉ, présence d'un enregistrement SOA, etc.) et pourquoi ce type de L'aliasing "sans référence" viole de nombreuses attentes des serveurs DNS au niveau fonctionnel. Et ce n'est que pour commencer. Cette question n’est pas un bon sujet ici, car elle est spéculative et n’est pas enracinée dans un problème que vous pourriez rencontrer en travaillant avec un serveur DNS conforme aux normes, correctement conçu.
Andrew B

6
@Ekevoo On peut soutenir que les implémentations HTTP auraient dû être adoptées à la SRVplace, ce qui aurait également permis d' éviter tout problème. Le problème ne se limite pas à ce qui est discuté ici; CNAMEcontrairement à la croyance populaire, ne correspond pas parfaitement à ce qui est nécessaire. En fin de compte, comme CNAMEcela ne fonctionne pas comme prévu (!), Il ne peut pas être repensé rétroactivement et, comme les implémentations HTTP ne l'utilisent pas, SRVil semble plus probable que la fonctionnalité de style "alias" devienne plus courante pour prendre en charge HTTP (type d'enregistrement spécifique). aliasing implémenté dans les coulisses plutôt qu'en tant que type d'enregistrement visible)
Håkan Lindqvist

2

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.


2
"Espérer"? Il existait déjà une "solution", à savoir les enregistrements HTTP SRV, mais ceux-ci ont été universellement rejetés. Ce qui n'est pas clair, c'est quel est le "problème".
Michael Hampton

Je n'étais même pas au courant de HTTP SRV, donc je ne sais pas pourquoi il a été rejeté. Espérons que cette nouvelle solution potentielle obtiendra une meilleure réception chaque fois qu’elle sortira.
Daniel Liuzzi

0

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".


3
C'est une interprétation incorrecte. Reportez-vous à la deuxième ligne du tableau de la RFC 6672 §2.2 . Un nom DNAME apex n'entraînera aucune correspondance pour les types de requête autres que DNAME à l'apex, c'est-à-dire qu'il n'entraînera pas de crénelage réel d'un enregistrement apex A ou AAAA.
Andrew B

Un nom DNAP apex n'entraînera aucune redirection pour les requêtes portant le nom de l'apex. Ce n’est pas techniquement correct de dire que cela ne donnera aucune correspondance . Vous obtiendrez tout de même une correspondance si vous interrogez NS, SOA ou tout autre type de RR présent pour le nom de l'apex. De la RFC 6672 : « Si un enregistrement DNAME est présent au sommet de la zone, il est encore nécessaire d'avoir les dossiers habituels de ressources SOA et NS là aussi Un tel DNAME ne peut pas être utilisé pour. Miroir complètement une zone, comme il le fait pas refléter le sommet de la zone. "
Quuxplusone
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.