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


C'est un Question canonique à propos des CNAME aux sommets (ou racines) des zones

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

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

Dans le meilleur des cas, le logiciel de 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 qu’elle n’était pas carrément interdite par la norme définissant les RFC et que leur le 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 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, le RFC n’est qu’informationnel. Le plus proche que je connaisse du verbiage qui interdit la pratique est de RFC1034:

Si un RR CNAME est présent sur un nœud, aucune autre donnée ne doit être   présent; cela garantit que les données pour un nom canonique et ses alias   ne peut pas être différent.

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 la plupart des concepteurs de logiciels. 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 obtenions vraiment techniques sur la folie des CNAME au sommet, et ne pas contourner le problème comme nous le faisons habituellement lorsque quelqu'un poste sur le sujet. RFC1912 est hors limites, comme tout autre RFC Informational applicable ici auquel je n'ai pas pensé. Fermons ce bébé.


107
2017-07-19 10:53


origine


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


Réponses:


CNAME les enregistrements étaient initialement créé pour permettre à plusieurs noms qui fournissent 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 gens qui viennent d'un milieu d'hébergement Web s'attendent à CNAME enregistrements à indiquer équivalence dans le DNS, ce qui n'a jamais été l'intention. Le sommet contient des types d’enregistrements clairement ne pas utilisé dans l'identification d'une ressource hôte canonique (NS, SOA), qui ne peuvent être aliasés sans enfreindre la norme à un niveau fondamental. (particulièrement en ce qui concerne coupes de zone)

Malheureusement, la norme DNS originale a été rédigée avant que les organismes qui la régissent ne se rendent compte qu'un verbiage explicite est nécessaire pour définir un comportement cohérent (RFC 2119). Il fallait créer RFC 2181 clarifier plusieurs cas en raison de la formulation vague, et le verbiage mis à jour montre plus clairement qu'un CNAME  ne peux pas être utilisé pour obtenir 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      pour l'origine de la zone, qui, avec un début d'autorité      (SOA) sont les enregistrements obligatoires dans 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 indiquant une zone coupée sont les      propriété de la zone enfant créée, ainsi que tout autre enregistrement de la      origine de cette zone enfant ou de ses sous-domaines. Un serveur pour un      zone ne doit pas renvoyer de réponses faisant autorité pour les requêtes liées à      noms dans une autre zone, qui inclut les enregistrements NS, et peut-être A,      dans une zone coupée, sauf s’il s’agit également d’un serveur pour l’autre      zone.

Ceci établit que SOA et NS les enregistrements sont obligatoires, mais cela ne dit rien sur A ou d'autres types apparaissant ici. Cela 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 à côté d'autres types d'enregistrement. RFC 2181 supprime l'ambiguïté et énonce explicitement les types d'enregistrement autorisés à exister à leurs côtés:

10.1. Enregistrements de ressources CNAME

L’enregistrement DNS CNAME ("nom canonique") existe pour fournir le      Nom canonique associé à un nom d'alias. Il peut y avoir qu'un seul      tel nom canonique pour n'importe quel alias. Ce nom devrait généralement être      un nom qui existe ailleurs dans le DNS, bien qu'il existe quelques rares      applications pour les alias avec le nom canonique qui les accompagne      indéfini dans le DNS. Un nom d'alias (étiquette d'un enregistrement CNAME) peut,      si DNSSEC est en cours d'utilisation, avoir les RR SIG, NXT et KEY, mais ne pas avoir      autre informations.  C'est-à-dire pour toute étiquette dans le DNS (n'importe quel nom de domaine)      exactement l'une des affirmations suivantes est vraie:

 + 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 pseudonyme" dans ce contexte fait référence au côté gauche de la CNAME record. La liste à puces indique explicitement qu’un SOA, NS, et A les enregistrements ne peuvent pas être vus à un noeud où un CNAME apparaît également. Lorsque nous combinons cela avec la section 6.1, il est impossible pour un CNAME d'exister à l'apex car il devrait vivre aux côtés obligatoires SOA et NS enregistrements.

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


Mettre à jour:

Il semble que la confusion la plus récente vient de Décision récente de Cloudflare pour 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 à RFC" décrit dans l'article lié au fait 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 parce qu’ils ne le permettent pas. (comme le montre ma question)


85
2017-07-19 10:53



Je suis d’accord avec cette preuve et je ne pense pas que ce chemin de preuve en deux étapes soit particulièrement long ou compliqué. (1. la zone apex est garantie d'avoir au moins SOA + NS enregistrements, 2. CNAME les enregistrements ne sont pas autorisés à coexister avec d'autres données) - Håkan Lindqvist
Globalement, je pense que c'est une très bonne explication. Si quelque chose pouvait être ajouté, je pense que ce serait peut-être plus d'expliquer ce qu'un CNAME record signifie en réalité, car il s'agit probablement du type d'enregistrement le plus mal compris. Même si cela dépasse un peu le propos, je pense que le fait d'être une FAQ est le résultat direct du fait que beaucoup (la plupart?) N'ont pas une bonne compréhension de CNAME. - Håkan Lindqvist
@ 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
@DenisHowe en bref: "un domaine" n'existe pas sans les enregistrements NS et SOA. ce sont les enregistrements non facultatifs. - hakamadare
@Ekevoo On peut soutenir que les implémentations HTTP auraient dû être adoptées SRV au lieu de cela, cela aurait également fait en sorte que cela ne pose pas de problème. Le problème ne se limite pas à ce qui est discuté ici; CNAME contrairement à la croyance populaire, ne correspond pas parfaitement à ce qui est nécessaire. À la fin, comme CNAME ne fonctionne pas comme prévu (!) et ne peut pas être repensé de manière rétroactive et les implémentations HTTP n'utilisent pas SRV il semble plus probable que la fonctionnalité de style "alias" devienne plus courante pour prendre en charge HTTP (aliasing spécifique au type d'enregistrement implémenté en arrière-plan plutôt qu'en tant que type d'enregistrement visible) - Håkan Lindqvist


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 sur      (potentiellement) renvoyer des données correspondant à un nom de domaine différent      à partir du nom de domaine demandé. La différence entre les deux      enregistrements de ressources est que le RR CNAME dirige la recherche de données à      son propriétaire à un autre nom, alors qu'un RR DNAME dirige les recherches      pour les données chez les descendants du nom de son propriétaire aux noms correspondants      sous un autre (unique) nœud de l’arbre.

Par exemple, prenons l’observation d’une zone (voir RFC 1034 [RFC1034],      Section 4.3.2, étape 3) pour le nom de domaine "foo.example.com", et un      L'enregistrement de ressource DNAME se trouve sur "example.com", indiquant que tous      les requêtes sous "exemple.com" soient dirigées vers "exemple.net". La recherche      processus reviendra à l'étape 1 avec le nouveau nom de requête de      "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".


0
2018-03-27 15:41



C'est une interprétation incorrecte. Reportez-vous à la deuxième ligne du tableau dans RFC 6672 §2.2. Un nom DNAME d’apex ne correspond à aucun type de requête autre que DNAME, c’est-à-dire qu’il n’entraîne pas de crénelage réel d’un enregistrement Apex A ou AAAA. - Andrew B
Un nom DNAP apex n'entraînera pas redirection pour les requêtes sur le nom du sommet. Ce n’est pas techniquement correct de dire que cela ne donnera pas rencontre. Vous obtiendrez toujours une correspondance si vous interrogez NS, SOA ou tout autre type de RR réellement présent pour le nom du sommet. De RFC 6672: "Si un enregistrement DNAME est présent au sommet de la zone, les enregistrements de ressources SOA et NS usuels sont également nécessaires. Un tel DNAME ne peut pas être utilisé pour miroir une zone complètement, car il ne miroir l'apex de la zone ". - Quuxplusone