Résumé

  • Pour une zone, la RFC 10001 exige au moins deux serveurs faisant autorité joignables en IPv4 et deux en IPv6. Un même serveur double pile compte une fois dans chaque famille ; les quatre preuves ne désignent donc pas nécessairement quatre machines.
  • Un NS, une adresse A ou AAAA et la glue décrivent une délégation voulue. La preuve opérationnelle doit encore montrer un chemin complet qui ne dépend pas de l’autre famille, une réponse UDP et TCP et des données faisant autorité équivalentes.
  • Tobias Fiebig a coécrit cette Best Current Practice d’août 2026 avec Momoka Yamamoto. Le texte collectif fixe un minimum commun sans attribuer à l’IETF, aux auteurs ou à un record le pouvoir d’exploiter réellement la zone.

Prenons une migration ordinaire. Le fournisseur sortant dessert encore la zone. Le fournisseur entrant a chargé les données et transmis ses noms de serveurs. La délégation du parent vient d’être modifiée. Pendant plusieurs heures, les caches et les chemins ne voient pas tous la même combinaison.

Un contrôle effectué depuis le réseau du nouveau fournisseur réussit. Un ordinateur double pile réussit aussi. Pourtant, un résolveur qui ne dispose que d’IPv6 n’atteint pas l’un des noms hors de la zone : l’adresse AAAA existe, mais la chaîne qui permet de la résoudre comporte une dépendance encore accessible seulement en IPv4.

Le terme « double pile » ne décrit pas cette panne. Il décrit une intention d’architecture.

La RFC 10001, publiée en août 2026 et intégrée à la BCP 91, remplace la généralité par des obligations observables. Momoka Yamamoto et Tobias Fiebig en sont les auteurs. Le document rend obsolète la RFC 3901, conçue à une époque où la préservation de la continuité IPv4 dominait encore le problème.

La nouvelle formulation traite les deux familles avec une symétrie exigeante. Une zone doit disposer d’au moins deux serveurs faisant autorité joignables en IPv4 et deux joignables en IPv6. Le mot « joignable » signifie que le serveur reçoit les requêtes DNS par la famille concernée et y répond. Il ne se réduit pas à la présence d’une adresse.

Cette exigence produit quatre cases de contrôle. Elle ne commande pas quatre ordinateurs distincts. Deux serveurs double pile peuvent fournir deux preuves IPv4 et deux preuves IPv6. À l’inverse, quatre adresses publiées derrière le même service défaillant ne donnent aucune preuve utile.

La glue ne garantit pas la fin du trajet

Une délégation est une suite, non une ligne unique. Le parent publie les NS. Si le nom d’un serveur se trouve dans l’espace qu’il doit lui-même rendre accessible, la glue fournit l’adresse nécessaire pour rompre la dépendance circulaire. Si le nom est extérieur à la zone, son propre domaine et ses parents deviennent des dépendances.

La RFC 9471 explique le rôle de la glue dans les réponses de délégation. La RFC 10001 ajoute la discipline de famille : la résolution en IPv4 du parent, des noms frères et de la glue ne doit pas dépendre d’IPv6. La chaîne IPv6 ne doit pas dépendre d’IPv4.

Il faut donc tester la chaîne dans les deux sens, avec des environnements réellement limités à la famille visée. Une machine double pile n’est pas une bonne preuve si son résolveur abandonne silencieusement IPv6 et termine le travail en IPv4. Le résultat final est utile à l’utilisateur, mais il efface la localisation du défaut.

L’étude How Ready is DNS for an IPv6-Only World? avait rendu ce mécanisme visible en 2023. Tobias Fiebig figure parmi ses sept auteurs. L’équipe ne s’est pas contentée de compter les AAAA ; elle a examiné si la chaîne complète pouvait être parcourue en IPv6.

Ses chiffres doivent rester datés. Pour août 2022, 44,9 % des zones observées dans les jeux de données de l’étude n’étaient pas résolubles en IPv6. Dix opérateurs concentraient 24,8 % des zones encore non résolubles. En janvier 2017, l’ajout de glue IPv6 par un seul fournisseur avait changé le résultat pour plus de 45,6 millions de zones.

Ce ne sont pas des taux actuels de l’Internet. Ils dépendent du corpus, des points d’observation et de la méthode décrits par les chercheurs. Ils démontrent en revanche qu’un petit nombre de dépendances de délégation peut affecter une très grande population de noms.

Deux réponses peuvent raconter deux zones

Une fois l’adresse atteinte, le contrôle n’est pas terminé. La RFC 10001 exige que les transports IPv4 et IPv6 servent des données DNS équivalentes. Une migration par étapes peut laisser une ancienne version de la zone sur une interface et une nouvelle sur l’autre. Les deux serveurs répondent ; les utilisateurs ne reçoivent pourtant pas la même autorité.

L’équivalence ne signifie pas une égalité octet par octet. L’ordre des records, les signatures, l’anycast ou certaines politiques de réponse peuvent produire des variations légitimes. L’opérateur doit définir ce qui compte : SOA, DNSKEY, délégations, enregistrements critiques, statut d’autorité et version du déploiement.

Le transport ajoute une autre limite. Une petite réponse UDP peut réussir là où une réponse DNSSEC plus grande est fragmentée ou rejetée. La RFC 10001 reprend les précautions de la RFC 9715 et impose la disponibilité du DNS sur TCP comme solution de repli, conformément à la RFC 9210.

Une vérification de port ne suffit pas. Il faut obtenir une transaction DNS complète en UDP, provoquer ou sélectionner un cas où TCP est pertinent, conserver la famille et le point de mesure, puis enregistrer le délai et le contenu obtenus. La fragilité de la fragmentation IP, exposée dans la RFC 8900, est précisément la raison pour laquelle un petit paquet vert ne peut représenter toutes les réponses.

Quatre preuves, six propriétaires

La difficulté de la migration vient aussi du partage du pouvoir. Le propriétaire de la zone décide des NS et des données enfant. Le registre ou l’opérateur du parent publie la délégation et la glue. Le fournisseur autoritatif gère les processus, les versions de zone et une partie de la capacité. Les équipes réseau contrôlent routes, filtres et MTU.

Les résolveurs récursifs constituent encore un autre plan. La RFC 10001 recommande qu’ils soient double pile. Un résolveur monofamille peut employer une traduction ou transférer les échecs à un résolveur double pile. Deux résolveurs monofamille opposés ne doivent cependant pas se renvoyer mutuellement les requêtes impossibles : une zone inaccessible par les deux chemins pourrait tourner en boucle.

Enfin, la mesure possède sa propre autorité. Elle choisit les points d’observation, les requêtes, le serveur ciblé, les délais et la conservation des résultats. Si le fournisseur se mesure uniquement depuis son réseau, il peut prouver son service local sans prouver le chemin des utilisateurs.

Une preuve exploitable doit donc porter un sujet et une date : nom NS, adresse, famille, source de la glue, chaîne suivie, point d’observation, résultat UDP, résultat TCP, version des données, heure, changement associé et équipe responsable. Chaque case verte reste bornée à ces paramètres.

Ce niveau de détail n’exige pas un produit unique. C’est un minimum d’échange entre équipes. Une feuille structurée ou un enregistrement signé peut suffire, à condition que personne ne transforme « quatre adresses présentes » en « quatre services observés ».

Une trajectoire de recherche, pas une autorité d’exploitation

Le profil officiel de la TU Wien indique que Tobias Fiebig est devenu professeur des universités en réseaux informatiques le 1er mars 2026. Il dirige le groupe Internet Infrastructures, avec des travaux sur la mesure, la sécurité, le développement des protocoles, DNS, SMTP, BGP et les conditions humaines de la coopération opérationnelle.

Ce parcours éclaire l’attention portée aux mesures et aux dépendances. Il ne prouve pas que Fiebig commande une infrastructure autoritative, qu’il a inventé seul la règle ou qu’une université l’a déployée. La RFC est cosignée avec Momoka Yamamoto et représente un consensus de l’IETF. L’étude de 2023 est le travail de sept chercheurs.

La contribution documentée est une manière de fermer l’écart entre configuration et service. Elle rejoint la primauté du code en fonctionnement formulée par Heng Lu : la déclaration administrative prépare l’expérience, mais ne la remplace pas. Une adresse n’est pas encore une réponse.

Le principe de spécification initiale minimale apporte la limite opposée. La règle commune ne doit pas dicter tous les choix locaux. La RFC 10001 fixe la joignabilité par famille, l’indépendance de la délégation, l’équivalence des données et le secours TCP. Elle laisse ouverts le fournisseur, la topologie, l’anycast, la distribution géographique et l’outil de mesure.

Cette liberté n’affaiblit pas le contrat. Elle oblige chaque opérateur à documenter comment son architecture produit les quatre preuves et quels risques restent corrélés.

Clore une migration sans confondre disparition et réussite

Un plan de migration peut désormais être écrit comme une suite de conditions. Les données enfant et parent sont cohérentes. Les délais de cache prévus sont passés. Chaque serveur requis répond depuis des points IPv4 seulement et IPv6 seulement. UDP, TCP et les réponses volumineuses ont été exercés. Les données critiques sont équivalentes.

L’ancien fournisseur ne doit être retiré qu’après une période d’observation définie. Sinon, le changement de délégation peut devenir difficile à inverser alors que certains résolveurs conservent encore des états intermédiaires. Le succès apparent d’une population double pile ne constitue pas un filet de sécurité pour les utilisateurs monofamille.

La même matrice sert à l’incident. Si la résolution IPv6 échoue, on cherche la première rupture : AAAA absent, glue périmée, dépendance extérieure, route manquante, UDP filtré, TCP fermé, zone divergente ou délai excessif. Le diagnostic devient une chaîne causale plutôt qu’un verdict vague sur « le DNS ».

Il faut également consigner les dépendances communes. Deux noms différents peuvent pointer vers le même répartiteur. Deux adresses peuvent partager la même route. Deux fournisseurs commerciaux peuvent dépendre d’un même opérateur amont. Quatre preuves présentes à un instant ne décrivent pas automatiquement quatre domaines de panne.

La conclusion n’est donc pas que quatre lignes rendent une zone invulnérable. Elles rendent la promesse réfutable et réexécutable. C’est assez pour décider honnêtement d’une mise en production, d’un maintien provisoire ou d’un retour arrière.

Sources