Résumé

  • Créé par le RFC 2672 en 1999, DNAME remplace le suffixe commun de tous les noms descendants par un autre suffixe. Une règle peut ainsi prendre la place d’une collection ouverte de CNAME.
  • La redirection ne touche pas le propriétaire du DNAME et ne crée pas de délégation. L’apex conserve SOA et NS ; la délégation demeure un jeu de NS à une coupure de zone ; l’opérateur de la cible garde le contrôle des données finales.
  • Le RFC 6672 a converti l’expérience de déploiement en limites vérifiables : CNAME synthétisé, preuve DNSSEC fondée sur le DNAME signé, données descendantes occultées, DNAME générique déconseillé, boucles bornées et YXDOMAIN si le nom produit est trop long.

Entre l’alias d’un nom et la délégation d’une zone

Le DNS de RFC 1034 savait déjà exécuter deux changements très différents. Un CNAME disait qu’un nom précis était l’alias d’un autre. Un jeu de NS placé à une coupure indiquait au résolveur quels serveurs faisaient autorité pour une zone enfant.

Ces deux gestes ne couvraient pas le besoin d’un administrateur qui voulait conserver toute la partie gauche d’un nom et seulement changer sa terminaison. Rediriger www.ancien.example avec un CNAME ne réglait pas le sort de mail.ancien.example, de atelier.mail.ancien.example ni des noms futurs. Déléguer ancien.example modifiait en revanche le chemin d’autorité, alors que l’objectif pouvait n’être qu’une continuité de nommage.

Il manquait donc une opération intermédiaire : plus large qu’un alias ponctuel, moins politique qu’une délégation. C’est précisément dans cet écart que DNAME fut conçu.

Une substitution de suffixe, pas une copie

RFC 2672 publia en août 1999 le type 39, nommé DNAME. La règle remplace le nom propriétaire, lorsqu’il constitue le suffixe d’un nom descendant, par le nom cible. Seules les étiquettes DNS entières correspondent.

Avec un DNAME de ancien.example vers nouveau.example, la recherche de www.lab.ancien.example devient celle de www.lab.nouveau.example. Les étiquettes www.lab sont conservées. Il ne s’agit ni de copier une zone ni de transférer ses serveurs : le résolveur poursuit simplement un autre nom calculé.

Le document d’origine associait ce mécanisme au renumérotage des réseaux, notamment dans le DNS inverse, ainsi qu’au changement de nom d’une organisation. Ces cas expliquent la conception ; ils ne mesurent pas son adoption. Leur point commun était l’économie administrative : une instruction devait couvrir des descendants connus et inconnus.

Cette économie concentrait aussi le risque. Modifier une règle pouvait modifier le parcours de tout un sous-arbre. Le type était compact dans le fichier de zone, mais immense par le nombre de requêtes auxquelles il pouvait s’appliquer.

Le propriétaire ne partait pas

La révision normative, RFC 6672, insiste sur une exception structurante : DNAME s’applique aux noms sous son propriétaire, jamais au propriétaire lui-même. Si ancien.example porte le DNAME, www.ancien.example peut être redirigé ; ancien.example ne l’est pas automatiquement.

D’autres données compatibles peuvent donc vivre au propriétaire. À l’apex d’une zone, les SOA et NS habituels restent indispensables. Un DNAME ne peut pas reproduire une zone entière, car son apex reste attaché à sa propre administration.

Dans un renommage d’organisation, ce détail impose de répéter éventuellement un MX à l’ancien apex. Il impose aussi de configurer le service cible pour accepter les anciens noms. Le DNS peut amener une requête jusqu’à une nouvelle adresse logique ; il ne peut contraindre un certificat, un serveur web ou une politique de courrier à reconnaître l’ancienne identité.

L’exception révèle la véritable promesse : DNAME ne dit pas « ce domaine a déménagé ». Il dit « pour les descendants, réécrire ce suffixe pendant la résolution ».

Une règle générale rendue lisible sous forme de CNAME

Lorsqu’un serveur applique le DNAME, il renvoie l’enregistrement et synthétise un CNAME propre à la question. Pour www.lab.ancien.example, le CNAME produit relie ce nom exact à www.lab.nouveau.example. Il n’existait pas nécessairement dans la zone ; il est la conséquence mécanique de la règle.

Ce pont permet aux clients qui comprennent CNAME de suivre la redirection. Il sépare la politique compacte — le DNAME — de son résultat transactionnel — le CNAME calculé. Les résolveurs cache récursifs doivent eux aussi savoir effectuer cette synthèse.

Le RFC 6672 a modifié la règle de durée de vie. Le CNAME synthétisé reçoit désormais le TTL du DNAME, alors que des implémentations plus anciennes utilisaient zéro. Les résolveurs doivent accepter les deux, afin qu’une clarification du standard ne transforme pas le code déjà déployé en panne.

La révision a également supprimé l’idée d’un signal EDNS de compréhension de DNAME : aucun signal n’avait jamais été défini. L’interopérabilité devait venir du comportement observable, pas d’une capacité imaginaire.

DNSSEC authentifiait l’instruction

Une zone ne peut pré-signer un CNAME pour chaque nom descendant qu’un utilisateur pourrait inventer demain. DNSSEC protège donc le DNAME, et non chaque CNAME synthétisé.

Le validateur vérifie la signature du DNAME puis recalcule la substitution. Si le CNAME non signé correspond exactement au propriétaire interrogé, aux étiquettes préservées et à la cible signée, sa dérivation est prouvée. L’absence de signature sur le résultat ne signifie pas absence de preuve ; la preuve réside dans une règle authentifiée et un calcul déterministe.

Cette protection ne se propage pas magiquement à toute la destination. Une chaîne peut rencontrer un autre DNAME, un CNAME, une zone non signée ou une erreur. RFC 6604 précise que le RCODE et les bits d’état doivent décrire le résultat terminal de la chaîne. Une première redirection valide ne transforme pas une cible inexistante en succès.

La chaîne est donc aussi forte que ses preuves pertinentes. Signer le pointeur prouve qui l’a publié ; cela ne prouve ni l’identité institutionnelle ni la sûreté du service vers lequel il pointe.

Pointer n’était pas déléguer

RFC 9499 définit comme alias le sous-domaine d’un propriétaire DNAME. Il réserve le mot délégation au processus par lequel un jeu de NS est ajouté dans la zone parente à l’origine de la zone enfant, sur une coupure de zone.

La différence détermine qui répond. Une délégation modifie le chemin d’autorité du résolveur. Un DNAME modifie le nom recherché ; ce nouveau nom emprunte ensuite les délégations qui existent déjà pour la cible.

Le RFC 6672 interdit qu’un DNAME partage avec un jeu de NS de délégation un propriétaire qui n’est pas un apex. Si le DNAME appartient à la zone enfant, il doit être placé sous la coupure, à l’apex enfant, avec les SOA et NS qui continuent de décrire cette zone.

Trois commandes restent séparées. L’opérateur source publie l’alias. Les opérateurs parent et enfant maintiennent la délégation source. L’opérateur cible contrôle les données finales. Le premier peut orienter une recherche vers le troisième ; il ne peut pas, par ce geste, lui transférer l’autorité d’origine ni commander sa disponibilité.

Ce qui vivait sous la règle devenait invisible

Une zone ne doit pas contenir de données sous le propriétaire d’un DNAME. Si un serveur les charge tout de même, elles sont occultées : le parcours rencontre la règle avant elles et repart vers la cible.

L’ajout d’un DNAME peut ainsi cacher des enregistrements qui n’ont pas été supprimés. Pendant la transition, les caches récursifs peuvent posséder d’anciennes données descendantes et un nouveau DNAME. Le RFC autorise plusieurs traitements temporaires et compte sur l’expiration des TTL pour rétablir la cohérence.

Déployer la règle exige donc un inventaire préalable du sous-arbre. Il faut tester l’apex séparément, mesurer la survie des anciennes réponses et planifier un retour arrière qui tient compte des caches. Retirer le DNAME du serveur autoritaire ne révoque pas instantanément les copies encore valides ailleurs.

Un propriétaire ne peut porter qu’un seul DNAME, et aucun CNAME au même endroit. Le protocole refuse ainsi deux instructions concurrentes. L’administrateur gagne une large portée, mais pas une pluralité ambiguë de destinations.

Quand le joker fabriquait la règle

Un DNAME normal est une règle publiée qui produit des conséquences par requête. Un DNAME porté par un nom générique ajouterait une étape : l’expansion du joker fabriquerait d’abord le propriétaire de la règle, puis cette règle fabriquerait une redirection.

RFC 4592 juge cette combinaison non déterministe et dangereuse pour la cohérence des caches. Le RFC 6672 la déconseille ; un serveur peut avertir, rejeter la mise à jour ou refuser la zone.

La limite protège la traçabilité. Une synthèse reste vérifiable lorsqu’un fait autoritaire fixe produit une conséquence unique. Si le fait qui confère le pouvoir de redirection est lui-même synthétisé différemment, l’origine et la portée de ce pouvoir deviennent difficiles à établir.

Ce n’est pas une hostilité aux automatismes. C’est une exigence de lisibilité : le système peut produire des réponses, mais la règle qui l’autorise doit rester stable, localisable et attribuable.

Boucles, longueur et coût

Les DNAME peuvent former des boucles entre eux ou avec des CNAME. Une règle peut même réinjecter un nom dans son propre espace de correspondance. Les résolveurs doivent limiter le travail consacré à une question, tout en admettant que certaines chaînes légitimes sont assez longues.

La substitution peut aussi dépasser la longueur maximale d’un nom DNS. Dans ce cas, le serveur autoritaire répond YXDOMAIN et joint le DNAME, ainsi que sa signature si la zone est signée. YXDOMAIN ne signifie pas que le nom demandé est simplement absent ; il signifie que l’opération produit un nom impossible à représenter.

Ces échecs répartissent les responsabilités. L’administrateur source répond du risque introduit par la règle. Le serveur autoritaire signale l’impossibilité de construire le résultat. Le résolveur borne les chaînes et les ressources. Aucun nom choisi par un client ne doit imposer un calcul illimité aux autres.

Les cibles de NS, MX, PTR et SRV doivent par ailleurs être des noms d’hôtes canoniques. Leur résolution d’adresse ne doit pas dépendre d’une chaîne CNAME ou DNAME. Le raccourci de nommage reste donc à l’écart des dépendances qui permettent au DNS lui-même d’avancer.

La continuité technique ne transfère pas la responsabilité

DNAME permet à une ancienne arborescence de rester utile pendant qu’une nouvelle reçoit les données. C’est un outil de transition puissant précisément parce qu’il ne prétend pas que rien n’a changé.

L’ancien opérateur continue de publier la règle. Le nouvel opérateur sert les données. Les applications acceptent — ou refusent — l’ancien nom. Les caches conservent des états pendant leur TTL. Chacune de ces surfaces a son propre propriétaire et sa propre preuve.

La leçon dépasse le DNS. Dans un réseau décentralisé, orienter une demande n’accorde pas automatiquement le droit de répondre en son nom. Une redirection réussie établit un chemin technique. Elle ne suffit pas à établir une continuité de propriété, de contrat ou d’obligation.

DNAME pouvait déplacer une recherche dans l’arbre. Il ne pouvait déplacer l’autorité qui structurait cet arbre. Cette incapacité était la garantie qui rendait son pouvoir de sous-arbre contrôlable.

Sources et limites des preuves

L’architecture initiale des CNAME, zones et délégations figure dans RFC 1034 : https://www.rfc-editor.org/rfc/rfc1034.html

La spécification originale et ses motivations figurent dans RFC 2672 : https://www.rfc-editor.org/rfc/rfc2672.html

Le problème du DNAME générique figure dans RFC 4592 : https://www.rfc-editor.org/rfc/rfc4592.html

Le résultat terminal des chaînes de redirection est clarifié dans RFC 6604 : https://www.rfc-editor.org/rfc/rfc6604.html

Les règles actuelles de substitution, synthèse, validation et erreur figurent dans RFC 6672 : https://www.rfc-editor.org/rfc/rfc6672.html

Les définitions actuelles d’alias et de délégation figurent dans RFC 9499 : https://www.rfc-editor.org/rfc/rfc9499.html

Ces textes ne donnent ni taux mondial actuel de déploiement ni gain opérationnel universel. Leurs exemples de renumérotage et de renommage sont des cas de conception. Une résolution DNAME réussie ne prouve ni propriétaire commun, ni acceptation applicative, ni validité de certificat, ni transfert d’autorité.