Résumé

  • Le RFC 9975 construit le périmètre du contrôle à partir de la délégation publiée par le parent : tous les noms NS, puis toutes leurs adresses, doivent être interrogés directement.
  • Une réponse NODATA participe à la comparaison ; une absence de réponse déclenche des tentatives supplémentaires, éventuellement depuis un autre point du réseau.
  • Si les vues pertinentes divergent, l’opération est abandonnée sans création, suppression ni modification des enregistrements du parent. L’accord ne remplace ni l’autorisation, ni l’identité, ni la validation DNSSEC du résultat.

Un serveur présente une nouvelle clé CDS. Un autre répond de façon authentique qu’il ne possède aucun enregistrement de ce type. Il n’y a ici ni majorité utile ni réponse « plus fraîche » que le parent pourrait deviner sans risque. Il existe deux états publiés par un même service de délégation.

Le cas paraît exceptionnel jusqu’au jour où une zone change de fournisseur, déploie une clé par étapes ou laisse une instance en retard. L’automatisation qui interroge le serveur le plus rapide réduit ce désaccord opérationnel à une décision irréversible dans la zone parente. Elle donne au hasard du routage une autorité que le protocole n’a jamais attribuée.

Publié en mai 2026 et signé par Peter Thomassen comme seul auteur, le RFC 9975 définit une autre discipline. Avant d’exécuter une demande CDS/CDNSKEY ou CSYNC, l’agent parental établit une « cohérence plausible » entre les serveurs faisant autorité. Il ne prétend pas connaître chaque paquet possible ; il documente un ensemble d’observations suffisamment complet pour ne pas confondre une vue partielle avec la volonté commune du service.

La liste des témoins vient du parent

Le point de départ n’est pas une liste fournie par le signal de mise à jour. L’agent lit les noms NS de l’enfant dans la délégation actuellement publiée par le parent. Pour chacun, il obtient toutes les adresses IP, y compris les données glue disponibles, au moyen d’une résolution validante. Il adresse ensuite la requête pertinente à chaque adresse.

Cette séquence a une fonction de contrôle. Si la demande pouvait choisir ses propres témoins, elle pourrait omettre le fournisseur qui publie encore l’ancien état. La délégation du parent est imparfaite, mais elle constitue la définition opérationnelle du service que le parent annonce déjà à l’Internet.

Une seule interrogation récursive du nom NS ne remplit pas ce contrat. Un nom peut conduire à plusieurs adresses, et une adresse anycast peut révéler des instances différentes selon le point d’observation. Le RFC permet donc une seconde perspective réseau lorsque la première ne reçoit rien. Il ne transforme pas la topologie en certitude ; il exige que ses limites soient visibles dans la décision.

NODATA n’est pas du silence

La règle la plus utile concerne l’absence. NODATA est une réponse faisant autorité : le serveur répond, mais ne publie pas le type demandé. Cette réponse entre explicitement dans le contrôle de cohérence.

Pour une opération CDS ou CDNSKEY, une clé visible d’un côté et absente de l’autre signale que la publication n’est pas achevée ou qu’elle est contradictoire. Supprimer NODATA de l’échantillon reviendrait à décider que seuls les serveurs qui demandent un changement ont le droit de voter.

Le silence réseau est différent. Une perte de paquets, un filtrage, un défaut de routage ou une panne peuvent empêcher toute observation. Le RFC recommande de réessayer selon une politique configurable et cite un recul exponentiel — 5, 10, 20 puis 40 minutes — comme exemple. Un autre point d’observation peut déterminer si l’échec appartient au serveur ou seulement au chemin.

Il n’est pas demandé d’attendre sans fin. L’opérateur doit toutefois nommer la règle qui classe finalement un serveur comme durablement inaccessible. La durée, le nombre de perspectives et l’escalade sont des choix locaux. Aucun d’eux ne doit convertir discrètement l’absence de preuve en preuve d’accord.

Le désaccord produit une non-opération atomique

Lorsque les réponses pertinentes ne sont pas cohérentes, le RFC 9975 ne propose pas de choisir la majorité, le numéro de série le plus élevé ou la première réponse. L’agent abandonne l’opération. Il ne crée aucun enregistrement prévu par cette opération, n’en supprime aucun et ne modifie pas l’ensemble existant.

Le statu quo n’est pas déclaré parfait. Il est le seul état que le parent publie déjà et dont les conséquences sont connues. Face à deux demandes incompatibles, passer à l’une d’elles peut rompre la résolution ou la chaîne DNSSEC. Ne rien changer laisse aux opérateurs de l’enfant le temps d’achever la réplication, de corriger une séparation entre fournisseurs ou de passer par une procédure authentifiée hors bande.

Un nouvel essai recommence les requêtes : il ne conserve pas seulement les réponses commodes d’un tour précédent. Le RFC permet aussi d’arrêter tôt certaines requêtes de décision dès qu’une réponse confirme le statu quo. Les réponses restantes ne pourraient alors que confirmer l’absence de changement ou révéler une incohérence, ce qui conduit également à ne rien changer. Des requêtes de rapport peuvent néanmoins continuer afin de conserver le diagnostic complet.

CDS et CDNSKEY comparent les clés utiles

La cohérence plausible n’est pas l’identité octet par octet de tous les paquets. Pour CDS et CDNSKEY, toute clé admissible référencée quelque part doit être référencée partout. Une clé présente sur un serveur et absente sur un autre rend l’état incohérent.

La suppression complète du jeu DS demande la même prudence. Une réponse qui demande cette suppression ne peut pas être combinée avec une autre qui propose une mise à jour ou renvoie NODATA. La politique des types de condensat fixe par ailleurs les formes qui entrent dans la comparaison ; les préférences locales du parent ne peuvent pas changer après coup le jeu de clés que l’enfant a effectivement présenté de manière cohérente.

Le RFC 10026, corédigé par Steve Sheng et Peter Thomassen et publié comme Best Current Practice en juillet 2026, place un contrôle distinct après celui-ci. Le jeu DS projeté doit encore préserver une validation DNSSEC correcte. Une demande unanime peut être techniquement dangereuse. La cohérence indique une intention partagée ; la validation continue vérifie la continuité du service.

CSYNC compare des décisions, pas tous les détails

Avec CSYNC, certaines différences sont normales. Le drapeau immediate et le bitmap de types doivent être identiques dans les réponses reçues. Les numéros de série SOA peuvent varier pendant la propagation ; chacun est donc évalué avec le SOA obtenu auprès du même serveur. C’est la décision résultante — mise à jour permise ou non — qui doit concorder.

Pour les ensembles de données que CSYNC demande de synchroniser, tels que NS ou les adresses associées, les RDATA pertinents doivent être égaux, y compris lorsque tous les ensembles sont vides. Les autres règles CSYNC, notamment l’ordre de traitement des serveurs de noms et de la glue, restent applicables.

« Interroger tout le monde » n’est donc qu’un titre. Une implémentation sérieuse possède un modèle de comparaison par famille d’enregistrements. Elle distingue la variation autorisée, l’étape transitoire et la contradiction qui interdit toute inférence.

Une notification accélère l’observation, pas l’autorité

Le RFC 9859, auquel Thomassen a également contribué, permet à une zone enfant de notifier qu’un état lié à CDS a changé. Le parent peut commencer rapidement ses contrôles au lieu d’attendre un balayage périodique.

La notification ne certifie rien. Elle lance les mêmes recherches DNS et les mêmes vérifications qu’un minuteur aurait déclenchées. Réception du message, collecte de toutes les vues, cohérence, validation du DS projeté, publication par le parent et visibilité après expiration des caches sont des reçus différents.

Les regrouper dans un unique statut « automatisé » masque précisément l’endroit où une vue partielle pourrait acquérir du pouvoir. La vitesse est une propriété du réveil ; l’acceptation reste une propriété de l’ensemble des preuves.

L’accord ne prouve ni identité ni mandat

Même un jeu cohérent n’établit pas qui possède le nom, qui avait le droit d’ordonner le changement au fournisseur DNS ou si un compte a été compromis. La validation DNSSEC existante peut authentifier certaines opérations de maintenance. Le premier amorçage nécessite une voie telle que le RFC 9615, car aucun DS parental ne permet encore ce contrôle. Les politiques de registre, de bureau d’enregistrement et de titulaire continuent d’exister en dehors de la comparaison.

L’application par le parent ne garantit pas non plus que tous les résolveurs voient aussitôt le nouvel état. Les caches conservent les anciens DS ou les anciennes données de délégation jusqu’à l’expiration des TTL. La séquence suivante d’un roulement de clé ne doit donc pas dépendre d’un simple accusé d’écriture.

Le RFC 9975 maintient une route authentifiée hors bande lorsque les opérateurs de l’enfant ne peuvent pas produire un état commun. Ce n’est pas une exception clandestine : c’est un autre chemin d’autorité. L’automatisation ne doit pas arbitrer un conflit de gouvernance en laissant gagner le premier serveur joignable.

Une paternité documentée n’est pas un contrôle universel

Le RFC Editor attribue le RFC 9975 à Peter Thomassen. Son profil public IETF le présente, au moment examiné, comme fondateur et directeur technique de deSEC, gérant de SSE, président de Domain Connect et secrétaire de DNSOP. Il figure aussi parmi les auteurs des RFC 9615, 9859 et 10026.

Ces éléments documentent sa contribution à la lignée technique. Ils ne prouvent pas qu’il exploite les agents parentaux, contrôle les registres, certifie les logiciels ou cause un incident particulier. Un standard décrit une règle minimale ; seuls les journaux d’un déploiement montrent quelles adresses ont été interrogées et si un conflit a réellement laissé le parent inchangé.

La symétrie est importante. Le nom d’un auteur établit une contribution, non un pouvoir sur toutes les implémentations. Le nom d’un serveur dans une délégation établit une source de preuve, non le droit solitaire de modifier le parent.

Le produit final est un reçu de décision

Le dossier reproductible conserve la délégation de départ, les adresses résolues et la provenance de la glue, les heures et points d’observation, chaque réponse pertinente ou NODATA, la validation, les comparaisons, les nouvelles tentatives et toute exclusion pour inaccessibilité durable.

Il ajoute le diff parental projeté, le contrôle de validation continue, la décision d’appliquer ou d’abandonner et l’état réellement publié après l’opération. Les secrets d’accès n’y ont pas leur place ; les éléments nécessaires pour refaire le raisonnement, oui.

La spécification minimale est commune : aucune modification de délégation ne doit être inférée d’un sous-ensemble incohérent. Les délais, canaux d’alerte, perspectives supplémentaires et politiques de condensat peuvent rester locaux. Le code en production dira si la frontière existe réellement.

Sources