Résumé

  • RFC 10001 remplace l’ancienne protection principalement IPv4 de RFC 3901 par une exigence symétrique : au moins deux serveurs faisant autorité joignables en IPv4 et deux en IPv6, des délégations indépendantes de l’autre famille et des données DNS équivalentes.
  • La présence d’un enregistrement A ou AAAA ne prouve ni la chaîne complète ni l’écoute du service. Il faut tester, pour chaque famille, les parents, la glue, les dépendances sœurs, UDP, TCP, le chemin réseau et l’usage final.

La zone paraît correctement déléguée. Deux noms de serveurs figurent chez le parent, chacun possède des adresses IPv4 et IPv6, et le résolveur de supervision reçoit une réponse. Pourtant, cette lecture tabulaire omet la question déterminante : quel chemin a réellement produit la réponse ?

Un résolveur double pile peut abandonner un chemin IPv6 brisé et réussir en IPv4. Son indicateur vert ne prouve pas une redondance ; il prouve seulement qu’au moins une carte reste praticable. Pour un client uniquement IPv6, la zone peut être hors d’atteinte dès une glue absente, un domaine frère non résoluble, un serveur qui n’écoute pas sur l’adresse annoncée ou un paquet abandonné silencieusement.

RFC 10001, publié en août 2026 comme BCP 91, appelle ce résultat un partitionnement de l’espace de noms. Le nom reste inscrit dans le DNS. Mais le résolveur arrive à un ensemble faisant autorité qui n’est joignable que par une famille qu’il ne possède pas. L’autorité publiée et l’autorité accessible se séparent.

Dessiner les dépendances avant de compter les serveurs

La résolution itérative part de la racine, reçoit une délégation, cherche les adresses des noms NS et recommence jusqu’au serveur enfant. Si un NS est dans la zone déléguée, le parent doit fournir la glue nécessaire. Si ce NS vit dans un domaine frère, la propre chaîne de ce domaine devient une dépendance. Chaque parent jusqu’à la racine doit fonctionner dans la famille considérée.

Une adresse AAAA placée au bon endroit n’est donc qu’une arête. Elle ne dit pas si le serveur répond, si la route existe, si un pare-feu laisse passer UDP et TCP, ni si le parent suivant demeure joignable. L’étude 2023 How Ready Is DNS for an IPv6-Only World?, citée par le RFC, a justement montré qu’un AAAA de serveur de noms ne suffisait pas : l’ensemble de la délégation devait être parcourable. Ses chiffres décrivent une mesure historique, non l’état universel d’août 2026, mais sa méthode reste la bonne unité de preuve.

La propriété appartient à un graphe réparti. Le parent maîtrise sa délégation et sa glue. L’enfant maîtrise ses données et ses écouteurs. Un domaine frère appartient à un autre opérateur. Le réseau maîtrise l’acheminement et la MTU. Le résolveur choisit, réessaie ou transfère. Aucun de ces acteurs ne peut déclarer seul que « le DNS fonctionne ».

Le basculement de RFC 3901

RFC 3901, en 2004, cherchait avant tout à ne pas fragmenter l’espace alors disponible aux hôtes IPv4. Il demandait au moins un serveur faisant autorité joignable en IPv4. Ce cadrage correspondait à un déploiement IPv6 encore expérimental.

RFC 10001 renverse l’asymétrie sans prétendre qu’une famille a gagné. Pour une zone, au moins deux serveurs faisant autorité DOIVENT être joignables en IPv4 et au moins deux en IPv6. Un même serveur double pile compte une fois dans chaque colonne. La délégation IPv4 ne doit pas dépendre d’IPv6 ; la délégation IPv6 ne doit pas dépendre d’IPv4. Les données servies par les deux transports doivent être équivalentes.

Cette dernière règle crée un contrôle distinct. Deux chemins disponibles qui livrent des RRsets ou des versions de zone différents ne préservent pas la continuité. Il faut rapprocher empreintes de réponses, numéros de série, validation DNSSEC et autorité, au lieu de réduire la conformité à un test de port.

La diversité recommandée par RFC 2182 demeure. Quatre adresses chez un seul fournisseur, sur une seule politique de routage et un seul processus de glue, peuvent constituer une seule panne. La bonne carte associe chaque nom NS à l’opérateur, au réseau, à la famille, au parent qui détient la glue, à l’écouteur réel et au chemin de supervision.

Le paquet peut casser une chaîne juste

Une configuration parfaite n’empêche pas les abandons liés à la MTU. Une grande réponse DNSSEC sur UDP peut être fragmentée ou dépasser la MTU effective. Sur TCP, des indications PMTU bloquées ou erronées peuvent faire choisir des segments trop grands. Le résultat visible reste souvent un simple délai d’attente.

RFC 10001 reprend RFC 9715 pour éviter la fragmentation. Il cite une limite supérieure de 1400 octets pour UDP et l’option plus prudente de 1232 octets ; pour TCP, des MSS émetteur de 1388 ou 1220 octets suivent les mêmes objectifs de taille. RFC 9210 maintient TCP comme voie de repli obligatoire.

Ce déplacement a un prix : moins de fragmentation peut produire davantage de connexions TCP. Le RFC mentionne une mesure de 3 à 5 % et demande de surveiller la charge locale. Il ne promet pas que ce taux s’applique à un autre portefeuille de zones. La preuve doit lier taille annoncée, taille réellement reçue, basculement TCP, latence et capacité serveur.

La traduction ne rend pas le chemin indépendant

Un résolveur récursif devrait normalement disposer des deux piles. Un résolveur à pile unique peut toutefois utiliser une traduction ou transférer ce qu’il ne peut résoudre à un résolveur double pile. Cette exception préserve la liberté d’architecture, mais elle ne doit pas falsifier la provenance.

Si NAT64 intervient, l’adresse IPv6 synthétique dépend encore d’une destination IPv4 et d’un préfixe PREF64. RFC 10001 renvoie à RFC 9872 pour découvrir ce préfixe de manière sûre. Une preuve « IPv6 réussi » doit donc préciser s’il s’agissait d’un accès natif ou traduit, ainsi que la source du préfixe et le traducteur utilisé.

Le transfert peut lui aussi créer une panne logique. Un résolveur IPv4 seulement et un résolveur IPv6 seulement ne doivent pas se renvoyer mutuellement les requêtes impossibles. Si une zone ne fonctionne dans aucune famille, la requête tourne sans fin. L’issue acceptable est un résolveur réellement double pile, jamais une boucle de délégation de responsabilité.

Tenir deux journaux, puis les réunir

Pour chaque zone critique, conserver une trace IPv4 seule et une trace IPv6 seule : point d’observation, heure, version du résolveur, réponses des parents, NS, A, AAAA, glue, domaines frères, adresse faisant autorité contactée, résultats UDP et TCP, taille EDNS, taille reçue, étape du délai, validation DNSSEC et empreinte du RRset.

Ajouter ensuite le résultat applicatif. Une réponse DNS n’établit pas que le client a choisi cette adresse et terminé sa transaction. Inversement, une connexion réussie ne reconstruit pas la chaîne DNS qui l’a permise. Conserver les deux évite d’attribuer à l’infrastructure une décision de l’application.

Les exigences techniques de l’IANA constituent une procédure distincte. RFC 10001 ne comporte aucune action IANA ; il invite l’IANA à envisager une mise à jour selon ses propres processus. Il serait donc faux de transformer la publication en preuve d’une règle déjà appliquée par tous les registres.

La primauté du code en fonctionnement de Heng Lu fixe la discipline : la norme décrit la possibilité et la cible ; seule la résolution observée prouve le chemin. Sa doctrine de spécification initiale minimale et d’adoption volontaire autorise un noyau commun strict pour l’interopérabilité, sans donner à la publication le pouvoir de masquer les coûts et décisions locales.

Un nom n’a pas une disponibilité abstraite. Il possède des chemins dont chacun doit produire sa propre preuve.