Résumé

  • La révision 14 du projet DNSOP sur la revalidation considère une délégation comme continue si le parent renvoie toujours vers le même point et si les anciens et nouveaux ensembles NS partagent au moins un nom ; lorsqu’un DS a été vu dans les deux états, au moins un signataire délégué doit également rester commun.
  • Un ensemble NS entièrement nouveau, un ensemble DS entièrement nouveau ou le passage entre absence et présence de DS signifie que l’autorité a changé. Le cache ne doit plus employer les données situées à ce point ou en dessous ; le mode strict et le mode opportuniste n’acceptent pas le même risque de panne.
  • Cette intersection sert à décider du sort d’un cache, pas à certifier le mandat d’une migration. Une fiche de transition devrait relier membres communs prévus, changement au registre, TTL, observation, échéance de retrait et responsable du repli. C’est une proposition de Daniel Kade, non une règle de l’IETF.

La délégation classique est un dialogue sans transaction commune. Dans la zone parente figurent les NS de renvoi, le glue nécessaire et, le cas échéant, les DS. À l’apex de la zone enfant figure un autre RRset NS, cette fois faisant autorité. Les deux équipes devraient les maintenir cohérents. Le protocole ne leur fournit pourtant pas un bouton qui modifie les deux côtés au même instant.

Les écarts sont donc ordinaires. Le parent peut imposer un TTL long tandis que l’enfant annonce un TTL court. Une file de registre peut terminer après la bascule des serveurs. Des réponses minimales peuvent omettre le NS d’apex dans les échanges habituels. Selon son logiciel et l’histoire des requêtes reçues, un résolveur peut préférer le parent, l’enfant, ou simplement la donnée arrivée au bon moment.

Le projet Delegation Revalidation by DNS Resolvers cherche à rendre ce comportement moins accidentel. Sa révision 14 date du 2 septembre 2026. Le Datatracker la classe comme Internet-Draft actif du groupe DNSOP, destiné au Standards Track avec le statut visé Proposed Standard, en attente du feu vert des présidents du groupe. Elle expire le 6 mars 2027. Ce n’est ni une RFC ni une obligation de déploiement.

Trois opérations forment son architecture. Après un renvoi, le résolveur interroge explicitement un serveur de l’enfant sur le NS d’apex et préfère cette réponse faisant autorité à la copie non autoritative du parent, conformément au classement de la RFC 2181. Il tente aussi d’obtenir des A et AAAA faisant autorité pour les noms de serveurs. Puis il revient périodiquement au parent afin de vérifier que le nom est toujours délégué à une autorité suffisamment continue.

Une règle d’intersection, pas une majorité

Pour revalider, le cache conserve les noms NS reçus du parent, leur TTL et le TTL du DS lorsqu’il en a observé un. Le parent doit encore produire un renvoi vers le même point. Le nouveau RRset NS du parent doit partager au moins un nom avec l’ancien. Si les deux observations comportent des DS, au moins un signataire délégué doit se retrouver des deux côtés.

Le mot « au moins » compte. Une configuration de quatre serveurs peut devenir un ancien plus trois nouveaux sans perdre sa continuité au sens de l’algorithme. Un roulement DNSSEC peut garder un signataire pendant que le suivant entre. La règle autorise ainsi une transition progressive sans traiter toute modification comme une nouvelle autorité étrangère.

Elle ne réduit toutefois pas la condition à une seule machine. Lorsque les DS existent dans les deux états, l’intersection des signataires est indépendante de celle des noms. Et le passage d’un RRset DS vide à un RRset non vide, ou l’inverse, constitue bien un changement d’autorité.

Si le parent ne renvoie plus de délégation, indique un autre point, ou présente un ensemble NS ou DS entièrement nouveau, les données mises en cache à ce point et sous ce point ne doivent plus être utilisées. L’implémentation peut les supprimer immédiatement ou les rendre inaccessibles par génération ; son comportement doit être celui d’un cache vidé.

Cette sanction forte explique pourquoi le test reste minimal. Il ne cherche pas à connaître le contrat entre titulaire et hébergeur DNS. Il ne vérifie pas l’identité d’un demandeur chez le registrar. Il ne sait pas si le serveur commun est une passerelle temporaire voulue, un service partagé, un résidu oublié ou un système compromis. Il établit seulement une continuité exploitable pour la résolution.

L’enfant décrit son service, le parent peut retirer le mandat

Le NS d’apex enfant a un rang supérieur parce que la zone enfant en est l’autorité. Le NS du parent sert au renvoi. Une application ordinaire ne demande presque jamais le RRset NS pour lui-même ; le résolveur doit donc lancer une requête de validation dédiée pour apprendre l’état autoritatif.

Si cette requête réussit, les échanges suivants peuvent utiliser la liste de l’enfant. Si elle échoue ou renvoie une absence de données, le parent demeure la meilleure voie disponible. Le mode opportuniste peut déjà avoir livré la réponse demandée par l’utilisateur avant que ce contrôle se termine.

Mais rafraîchir l’enfant sans revisiter le parent produirait une autre erreur. Le parent peut avoir retiré la délégation ou l’avoir confiée à un nouvel opérateur. Un ancien serveur qui continue à publier son apex pourrait alors entretenir indéfiniment la confiance d’un cache. La revalidation parentale borne précisément ce risque de domaine fantôme.

Les adresses compliquent encore la provenance. Le glue aide à atteindre les serveurs, mais il n’est pas nécessairement autoritatif. Une adresse complète, signée et validable par DNSSEC peut être promue sans nouvelle requête ; sinon il faut interroger son autorité. Le projet autorise néanmoins la conservation du glue inférieur comme dernier recours si toutes les adresses mieux classées sont injoignables.

Cette souplesse maintient le service. Elle empêche aussi un observateur de déduire le chemin réel à partir d’une seule photographie : rang de cache, joignabilité, ordre des réponses et décision de repli modifient tous l’issue.

Strict ou opportuniste : deux contrats d’exploitation

En mode strict, le résolveur peut retenir la réponse initiale jusqu’à savoir qu’elle vient d’un nom et d’une adresse obtenus de manière autoritative. Il réduit ainsi le risque de redirection ou d’écoute sur le chemin. En revanche, un apex enfant défectueux et l’absence de repli transforment le contrôle en panne dure.

La révision 14 recommande donc de limiter cette promotion stricte à la racine et aux zones directement déléguées par elle. Plus bas dans l’arbre, des serveurs répondent encore mal aux requêtes NS explicites. Une politique strictement uniforme ferait payer leur mauvaise administration aux utilisateurs.

Le mode opportuniste privilégie la continuité immédiate. Il répond, apprend ensuite, et abandonne l’algorithme pour une zone qui ne sait pas répondre à la requête d’apex. Il revient alors au renvoi parent. Cette tolérance n’offre pas la même protection que le mode strict.

Un opérateur doit donc documenter profondeur, mode, données de repli et comportement de purge. Le simple indicateur « revalidation activée » ne révèle pas ce qui se passera le jour où les deux côtés divergent vraiment.

Trois TTL, puis la limite choisie par le résolveur

Le contrôle doit intervenir au plus tard à l’expiration du plus court de trois TTL : NS parent, DS parent lorsqu’il existe, NS d’apex enfant. Le temps du parent borne la survie d’une autorité retirée. Celui de l’enfant lui permet de demander une observation plus rapide de son nouveau service.

Le projet conseille pourtant un plancher raisonnable afin qu’une zone ne puisse imposer une cadence de travail abusive avec un TTL minuscule. Il ne fixe pas de valeur universelle. Le titulaire ne peut donc pas promettre que tous les caches du monde appliqueront sa révocation à la seconde indiquée par son plus petit TTL.

Les échecs doivent être mis en cache négativement selon la RFC 9520, faute de quoi la revalidation elle-même martèlerait un serveur défaillant. Les requêtes supplémentaires sur NS et adresses peuvent d'ailleurs représenter un trafic important. Limiter le travail par résolution appartient au modèle de sûreté, pas seulement à l'optimisation.

Le rapport de désaccord n’est pas un jugement

Une différence entre le NS du parent et le NS d’apex peut être signalée, via la RFC 9567, aux canaux du parent et de l’enfant. Le projet demande un code Extended DNS Error propre au désaccord de renvoi, mais sa valeur reste TBD.

La différence peut être une étape normale de migration, un délai de registre ou une conséquence du TTL. Elle n’entraîne pas nécessairement un échec. Le rapport prouve qu’un résolveur a vu deux ensembles distincts à un moment donné ; il ne prouve pas lequel traduit le mandat contractuel, ni si le membre commun devait rester.

Il faut donc intégrer ces rapports à une réconciliation humaine. Un succès de résolution n’est pas davantage une approbation : un chemin résiduel peut répondre parfaitement tout en n’ayant plus de propriétaire opérationnel reconnu.

Une fiche de transition pour expliquer le membre restant

Lors d’un passage du prestataire A au prestataire B, garder un NS de A et un signataire ancien peut être une excellente précaution. Pour le résolveur, l’ensemble reste continu. Pour les exploitants, ce pont doit porter une date de fin et une responsabilité.

La fiche commence par quatre états séparés : NS et glue du parent, DS du parent, NS d’apex de l’enfant, adresses autoritatives. Elle distingue l’ancien état, l’état cible et l’intervalle autorisé. Elle nomme le NS et, si nécessaire, le signataire qui doivent demeurer communs, ainsi que le motif de ce maintien.

Elle relie ensuite ces données au changement de contrôle : référence du registrar ou du registre, ancien et nouvel opérateur DNS, approbateur du retrait final, responsable du retour arrière. La fiche ne remplace pas l’authentification et ne stocke aucun secret ; elle donne une piste vérifiable vers la décision.

Les trois TTL, le déclencheur le plus court et l’hypothèse de plancher des résolveurs figurent séparément. L’arrêt des modifications chez l’ancien fournisseur, le retrait du parent, l’arrêt des réponses autoritatives et la disparition du trafic ne sont pas une seule et même date.

La surveillance compare les chemins strict et opportuniste. Si un ensemble entièrement nouveau est volontaire, l’équipe prépare la purge des données descendantes et la hausse de requêtes au lieu de les découvrir comme une panne mystérieuse. La clôture exige enfin la convergence parent-enfant, le retrait du pont prévu, la fin des réponses inattendues de l’ancien service et l’expiration de la fenêtre de repli.

Aucun résolveur ne lit cette fiche et le projet ne l’exige pas. Elle remplit l’espace que le protocole laisse volontairement ouvert : l’algorithme sait mesurer la continuité ; l’organisation doit prouver qu’elle l’a voulue et bornée.

Sources

  1. Revalidation des délégations par les résolveurs DNS — révision 14
  2. Fiche Datatracker du projet
  3. Historique du document
  4. Documents actifs de DNSOP
  5. Charte de DNSOP
  6. RFC 1034 — Concepts et mécanismes du DNS
  7. RFC 2181 — Clarifications sur la spécification DNS
  8. RFC 9520 — Cache négatif des échecs de résolution
  9. RFC 9567 — Signalement des erreurs DNS
  10. Délégation extensible pour le DNS — révision 11