Résumé

  • draft-ietf-dnsop-ns-revalidation-14 donne la préférence au jeu NS autoritaire de l’apex enfant, mais oblige le résolveur à revenir vers le parent : un ancien enfant qui répond encore ne peut pas renouveler seul une délégation retirée.
  • La preuve exploitable est une chaîne datée : forme du referral parental, chevauchement des NS et des DS, plus courte des trois TTL, invalidation des descendants et nouvelle résolution. Une réponse isolée ne ferme pas cette chaîne.

L’autorité survivait dans le cache

Le transfert semblait terminé. Le parent désignait de nouveaux serveurs, leurs zones étaient chargées et les contrôles administratifs étaient clos. Pourtant, certains utilisateurs continuaient d’atteindre les anciens serveurs. Ceux-ci n’étaient ni arrêtés ni muets : ils répondaient avec des données cohérentes et se déclaraient autoritaires.

Ce tableau ne révèle pas nécessairement une panne de transfert. Il montre surtout que le DNS contient deux surfaces d’autorité autour d’une coupure de zone. Le parent publie un jeu NS de délégation. L’enfant publie son propre jeu NS à l’apex. Le protocole ne synchronise pas automatiquement les deux.

La révision 14 de draft-ietf-dnsop-ns-revalidation, datée du 2 septembre 2026, transforme cette divergence en décision de cache. Le document est un Internet-Draft actif du groupe DNSOP, destiné au statut Proposed Standard. Le Datatracker l’indique en attente du feu vert des présidents du groupe et à l’état I-D Exists. Il ne s’agit ni d’un RFC ni d’une mesure générale du déploiement.

Sa question est néanmoins immédiatement opérationnelle : qu’est-ce qui autorise un résolveur à continuer de croire un enfant après que le parent a peut-être changé d’avis ?

Le classement des données ne délègue rien

RFC 2181 classe le jeu NS autoritaire de l’enfant au-dessus du jeu NS non autoritaire fourni par le parent. Le choix est logique. L’enfant connaît ses serveurs. Il peut aussi publier un TTL plus court afin d’effectuer une migration plus rapidement qu’un registre dont le TTL de délégation est fixe et long.

Le résolveur doit donc chercher explicitement le jeu NS de l’apex enfant lorsqu’il franchit une nouvelle coupure de zone, puis le préférer en cache. Il peut interroger en parallèle le DNSKEY d’une délégation sécurisée. Les adresses A et AAAA obtenues comme glue ou données additionnelles peuvent également être réinterrogées afin de remplacer une adresse faiblement classée par une réponse autoritaire.

Mais cette amélioration de crédibilité ne vaut pas renouvellement d’autorité. Si l’enfant pouvait rafraîchir éternellement son propre jeu NS, l’ancien opérateur resterait visible après une redélégation. La preuve contestée se renouvellerait elle-même.

Le projet sépare donc deux verbes souvent confondus : apprendre de meilleures données auprès de l’enfant et revalider auprès du parent le droit actuel de les utiliser.

Trois TTL, trois pouvoirs

La revalidation doit intervenir au plus tard à l’expiration de la plus courte durée parmi le TTL du jeu NS parental, celui du jeu DS lorsqu’il existe et celui du jeu NS de l’enfant. Aucun de ces compteurs ne remplace les deux autres.

Le TTL NS du parent borne l’acceptation de la délégation. Le TTL DS borne la relation avec le signataire délégué. Le TTL NS de l’enfant borne l’actualité du groupe de serveurs qu’il affirme utiliser. La plus courte durée empêche un acteur de prolonger l’autorité d’un autre.

Le résolveur peut imposer un plancher raisonnable pour éviter qu’une zone aux TTL minuscules ne provoque un déni de service par calcul. Ce plancher appartient à la politique locale. Il doit être enregistré comme tel : il ne prouve pas que la délégation est demeurée identique pendant le délai ajouté.

Un tableau de bord qui n’affiche qu’une “date d’expiration DNS” fusionne donc trois décisions. Pour être auditable, il faut conserver les trois valeurs brutes, le plancher appliqué, l’instant de dernière vérification et l’instant limite réel.

La continuité se mesure par chevauchement

Au point de revalidation, le résolveur questionne à nouveau le parent. La délégation reste valide si le parent renvoie toujours un referral vers la même coupure, si le nouveau jeu NS partage au moins un nom de serveur avec le jeu parental conservé, et si les jeux DS présents avant et après partagent au moins un signataire délégué.

Une réponse qui n’est plus un referral, une coupure différente, un jeu NS entièrement nouveau ou un jeu DS entièrement nouveau signalent un changement de hiérarchie ou d’autorité. Le passage d’un jeu DS vide à non vide, ou l’inverse, appartient à la même catégorie.

Ce test autorise une migration progressive : un serveur ou un signataire commun peut assurer la continuité pendant que le reste change. Il ne certifie pas l’équivalence totale des deux configurations. Il répond à une question de sûreté du cache, non à une question de propriété juridique, de contrat de registre ou de bon fonctionnement applicatif.

Une chaîne familière n’est donc pas forcément une chaîne actuelle. Le nom d’un serveur commun est un élément de continuité, pas une preuve universelle de contrôle.

Le changement remonte dans tous les descendants

Lorsque l’autorité ou la forme de la hiérarchie a changé, les données en cache au point concerné ou en dessous ne doivent plus être utilisées. L’implémentation peut les supprimer immédiatement, changer de génération ou les invalider paresseusement. Pour les requêtes, le comportement doit être celui d’une suppression.

La portée dépasse les seuls NS. La délégation soutient les adresses d’hôtes, les routes de messagerie, les découvertes de services, les réponses négatives et les délégations plus profondes. Conserver ces résultats tout en remplaçant seulement le pointeur parent maintiendrait des conclusions dont la base d’autorité a disparu.

La revalidation s’effectue donc efficacement du haut vers le bas. Un changement supérieur peut rendre inutile toute vérification inférieure. RFC 8020 montre déjà comment une conclusion négative peut couvrir l’espace situé sous un nom. Ici, la leçon est symétrique : la disparition du support supérieur retire la validité opérationnelle de conclusions encore présentes en mémoire.

Le mode strict protège davantage et casse plus nettement

Le mode strict peut retenir la réponse déclenchante jusqu’à vérifier que le serveur possède un nom et une adresse acquis de façon autoritaire. Avec des données d’infrastructure signées, cette méthode réduit la possibilité de redirection.

Elle supprime aussi le filet de secours. Un enfant défectueux, ou un serveur qui répond mal aux requêtes NS explicites, peut provoquer un échec dur. C’est pourquoi le projet recommande de limiter l’amélioration stricte à la racine et aux zones directement déléguées depuis elle.

Le mode opportuniste accepte une autre économie. Le résolveur peut répondre avant la fin de la validation et revenir aux données du referral parental. Si l’enfant traite mal la requête NS, l’algorithme est abandonné pour cette zone. La disponibilité augmente, mais la protection n’est pas équivalente.

Le libellé “revalidation active” est donc insuffisant. Il faut savoir si la réponse attendait la preuve, si elle est sortie avant celle-ci, si un fallback a eu lieu et quelle génération de cache a réellement changé.

DNSSEC ne signe pas tout le trajet

DNSSEC authentifie des enregistrements essentiels, mais le jeu NS d’un referral, la glue et certaines adresses additionnelles ne sont généralement pas signés. Modifier une adresse non signée peut diriger le résolveur vers un serveur hostile, capable d’observer les requêtes et de modifier d’autres éléments non signés plus bas dans l’arbre.

RFC 5452 renforce la résistance aux réponses forgées par une meilleure correspondance des transactions et davantage d’entropie. La révision 14 traite une autre question : la crédibilité et la continuité de l’infrastructure suivie après la transaction.

Une validation DNSSEC réussie reste une preuve bornée. Elle n’établit pas que le retour au parent a eu lieu à temps, que le résultat a été appliqué, que tous les descendants ont été invalidés ou que l’application a rejoint le nouveau service.

Le diagnostic ne réalise pas la migration

Le document demande un code Extended DNS Error pour un désaccord entre jeux NS de referral. RFC 8914 permet d’expliquer plus précisément un échec au client ou à l’opérateur. Ce code améliore le diagnostic ; il ne répare ni le parent ni l’enfant.

Pour devenir une preuve, le signal doit rester lié à la réponse parentale exacte, au jeu comparé, au mode du résolveur, aux TTL, à l’action d’invalidation et à la nouvelle résolution. Sinon, il devient une étiquette sans décision reproductible.

RFC 9471 rappelle par ailleurs que la glue obéit à ses propres nécessités de referral. Une adresse nécessaire à l’amorçage n’acquiert pas pour autant l’autorité du parent, pas plus qu’une adresse joignable ne prouve la disponibilité d’un service.

Les implémentations citées ne forment pas un recensement

L’annexe de la révision 14 indique qu’Unbound propose depuis longtemps la revalidation opportuniste via harden-referral-path, option désactivée par défaut, et que la logique de la section 7 existe depuis la version 1.4.17. Elle indique aussi que Knot Resolver revalide la réponse d’amorçage de la racine. Enfin, elle ne connaît pas de déploiement du mode strict hors prototypes et outils des auteurs.

Ces indications prouvent une histoire de code. Elles ne prouvent ni la configuration d’un résolveur donné, ni les défauts d’une distribution actuelle, ni un taux d’adoption, ni un résultat d’interopérabilité. L’observation du binaire, de sa configuration et de ses transitions de cache reste nécessaire.

Le reçu opérationnel

Une exploitation défendable conserve : la version et la configuration du résolveur ; le referral parental initial avec NS, DS et glue ; le jeu NS autoritaire de l’enfant ; les adresses réinterrogées ; les trois TTL et le plancher local ; le point de revalidation ; la chaîne depuis la racine ; la nouvelle réponse parentale ; les chevauchements NS et DS ; tout changement vide/non vide ; la génération de cache invalidée ; le fallback ou l’échec dur ; l’éventuel EDE ; le nouveau serveur sélectionné ; puis une observation indépendante du service.

Cette séquence n’abolit pas le caractère distribué du DNS. Elle interdit seulement de transformer une réponse encore reçue en croyance illimitée. L’ancien enfant peut continuer à parler. Le résolveur doit néanmoins pouvoir montrer pourquoi il a cessé de lui reconnaître l’autorité actuelle.

Sources