Résumé

  • CNAME transforme un nom propriétaire en alias vers une seule cible. Pour que l’alias et sa destination ne livrent pas deux vérités incompatibles, ce nom ne peut plus porter de données ordinaires A, MX, TXT, NS ou équivalentes.
  • Le résolveur met le CNAME en cache et reprend la recherche à la cible. La zone source maîtrise le détour, l’autorité de la cible maîtrise les données finales ; ni l’une ni l’autre opération ne constitue une délégation ou une preuve d’identité.

Deux fonctions qui ne pouvaient pas habiter le même nom

Imaginons que portal.example soit un CNAME vers service.example.net. Une demande d’adresse reçoit d’abord l’instruction d’alias, puis le résolveur cherche A ou AAAA à la cible. Si la zone source publiait en plus sa propre adresse A pour portal.example, laquelle le cache devrait-il croire : celle attachée directement à l’ancien nom, ou celle obtenue après le détour ?

Le RFC 1034, publié en novembre 1987, n’a pas laissé ce conflit au goût des logiciels. Le propriétaire du CNAME est l’alias ; le nom placé dans le RDATA est la destination canonique. Lorsqu’un CNAME se trouve à un nœud, aucune autre donnée ordinaire ne doit s’y trouver.

La règle ne relevait pas de l’esthétique des fichiers de zone. Elle empêchait les données du nom canonique et celles de l’alias de diverger. Elle permettait aussi à un résolveur ayant mémorisé le CNAME de l’utiliser sans retourner auprès du serveur faisant autorité pour vérifier si un autre type contredisait l’instruction.

L’exclusivité donne donc au CNAME une autorité étroite : il ne dit pas quelle adresse ou quel service existe. Il dit où la question doit recommencer.

La réponse déplaçait la question

Un CNAME n’est pas un simple synonyme rendu comme texte. Si le QTYPE demandé n’est pas CNAME, l’algorithme du RFC 1034 ajoute le CNAME à la réponse, remplace le QNAME de travail par la cible et recommence la recherche. Une requête CNAME fait exception, car son auteur souhaite observer le détour lui-même.

Le RFC 9499 distingue aujourd’hui le QNAME original envoyé dans la question, les QNAME effectifs examinés au fil de la chaîne et le QNAME final. Une réponse peut donc répéter le nom initial dans sa section Question, tout en livrant des données dont le propriétaire est le dernier nom.

Cette précision évite une erreur lors d’un échec. L’alias peut exister et avoir été répondu avec autorité, alors que la cible n’existe plus, relève d’une autre zone ou connaît une défaillance. Un NXDOMAIN au bout de la chaîne ne prouve pas que l’alias initial n’a jamais existé.

Le détour ne déléguait rien

Alias et délégation obligent tous deux le résolveur à poursuivre, mais ils ne déplacent pas le même pouvoir. Un RRset NS à une coupure de zone désigne les serveurs qui font autorité pour la zone descendante. Le CNAME reste une donnée publiée par l’autorité source à propos de son propre nom. Il déclenche une autre recherche sans remettre la zone source à l’opérateur cible.

L’administrateur source choisit l’existence de portal.example, sa cible et son TTL. L’autorité de service.example.net choisit les A, AAAA ou autres données terminales et leurs TTL. Pointer vers la cible ne donne pas au premier le droit de la modifier ; recevoir le trafic d’un alias ne permet pas au second d’éditer le nom source.

Le RFC 6604 a clarifié les codes et indicateurs le long des chaînes CNAME et DNAME. La première étape peut être une réponse faisant autorité tandis que la suite produit un renvoi ou une erreur. L’autorité sur le premier énoncé ne devient pas une garantie du voyage entier.

Une cible par alias, pas un seul nom par machine

Le mot « canonique » a nourri une conclusion trop large : chaque hôte ou interface n’aurait droit qu’à un nom officiel. Le RFC 2181 rejette cette lecture. Le DNS ne fixe pas une identité unique pour une machine.

La contrainte porte sur un objet beaucoup plus précis : un propriétaire CNAME possède une seule cible canonique. Parler du propriétaire comme « un CNAME » brouille le sens ; ce propriétaire est l’alias, tandis que la valeur du record est le nom canonique de cette relation.

Plusieurs noms peuvent mener au même service. Un nom qui n’est pas alias peut aussi porter plusieurs RRsets ordinaires. Il lui est seulement interdit d’ordonner « poursuivez ailleurs » tout en prétendant répondre ici comme une destination indépendante.

Pourquoi l’apex ne pouvait pas prendre ce raccourci

L’apex d’une zone doit contenir SOA et NS. L’exclusivité CNAME empêche donc d’y placer un CNAME ordinaire. Le RFC 1912 documentait le danger : dans son exemple BIND historique, joindre un CNAME aux NS de l’apex pouvait conduire le serveur à ignorer les autres ressources, puis à rendre invisibles les noms sous la zone.

Le comportement exact appartenait aux versions de l’époque ; la contradiction appartient au modèle. Des fournisseurs peuvent aujourd’hui synthétiser des réponses d’adresse à l’apex ou proposer une fonction dite d’aplatissement. Ce produit peut être utile, mais il n’est pas un CNAME ordinaire présent sur le réseau. Confondre les deux rend l’autorité et le cache illisibles lors d’un incident.

NS et MX ne pouvaient pas cacher leur adresse derrière un alias

Le RFC 2181 interdit également un alias comme cible NS ou comme échange MX. Lors d’une réponse NS ou MX, le serveur peut joindre dans la section Additional les adresses du serveur ou de l’échangeur. Ce traitement ne poursuit pas un CNAME afin d’ajouter ensuite l’adresse du nom canonique.

Une cible alias impose donc des requêtes supplémentaires et peut, dans les cas difficiles de délégation, faire échouer la résolution. L’administrateur doit résoudre l’alias une fois et publier directement le nom qui possède les RRsets d’adresse.

Ce n’est pas une hostilité générale aux références entre noms. La restriction protège des positions où la découverte prévisible d’une adresse fait partie du chemin de fonctionnement.

DNSSEC ajoutait la preuve, pas une seconde destination

L’expression « aucune autre donnée » a reçu une exception nécessaire avec DNSSEC. Le RFC 2181 autorisait les records de sécurité de son époque ; le RFC 4034 exige ensuite RRSIG et NSEC au nom d’un CNAME dans une zone signée.

Ces records ne concurrencent pas la cible. RRSIG authentifie le RRset CNAME ; NSEC contribue à la preuve des types et de la non-existence. Ils décrivent et prouvent l’état du nœud alias sans lui rendre une adresse, une route de courrier ou un contenu applicatif propre.

Le RFC 4033 borne aussi la conclusion : DNSSEC peut fournir origine des données, intégrité et déni authentifié. Il ne certifie ni la santé du service cible, ni une personne, ni un contrat, ni le propriétaire juridique du nom source.

Une chaîne était permise ; une boucle devait être arrêtée

Un alias peut conduire à un autre alias. Le RFC 1034 déconseille les étages multiples pour leur coût, sans faire d’une chaîne finie une erreur. Le résolveur doit plutôt détecter les boucles et les chaînes aboutissant à un nom inexistant.

L’objet à surveiller est donc un graphe. Chaque arête a son propriétaire, son autorité, son TTL et parfois son état DNSSEC ; les RRsets terminaux ont une autre durée de vie. Deux caches peuvent présenter des étapes différentes d’une même migration parce qu’ils n’oublient pas les anciennes arêtes au même instant.

Ce découplage apporte aussi sa valeur. La source peut déplacer un nom familier sans recopier les données finales. La cible peut changer d’adresse sans modifier chaque zone qui lui fait référence. En contrepartie, les deux côtés évoluent séparément, tandis que les caches conservent leurs déclarations jusqu’à expiration.

La coordination minimale exigeait une vérité non mélangée

CNAME a réglé un problème de maintenance distribuée avec un mécanisme volontairement mince. Nul besoin d’un registre mondial de noms équivalents, ni d’un arbitre central décidant quelle adresse « appartient réellement » à l’alias. Il suffisait d’une arête sans ambiguïté que tout résolveur puisse mémoriser et suivre.

La règle d’exclusivité est le centre institutionnel de cette réussite. Le nom source peut être un détour ou une destination, jamais les deux. Une fois le détour choisi, son autorité reste réelle et limitée : publier une cible, conserver la provenance de la chaîne et laisser les données finales à leur propre autorité.

Sources et limites

Le modèle et l’algorithme d’origine viennent du RFC 1034 et du RFC 1035. Les erreurs d’exploitation et clarifications viennent des RFC 1912 et 2181 ; les exceptions DNSSEC des RFC 4033 et 4034 ; les statuts de chaîne et la terminologie des RFC 6604 et 9499. Ces textes ne prouvent ni la part de déploiement actuelle, ni l’aplatissement propre à un fournisseur, ni les limites contemporaines de chaîne, ni la fréquence des alias abandonnés, ni la propriété ou la disponibilité d’un service présent.