Résumé

  • La révision 05 de DNSSEC automation est un Internet-Draft actif de DNSOP, non un RFC ni une preuve de déploiement ; Datatracker et l’en-tête ne donnent même pas le même statut prévu.
  • Le texte organise l’entrée, la sortie et les rollovers d’un groupe multi-signataire autour de DNSKEY, CDS/CDNSKEY, CSYNC, DS et NS.
  • DS-Wait-Time, DNSKEY-Wait-Time, NS-Wait-Time et RRSIG-Wait-Time protègent des expositions différentes. Aucun ne peut commencer sur un simple envoi ou accusé de réception.
  • La synchronisation du contenu ordinaire de la zone est explicitement hors périmètre : des clés cohérentes peuvent signer des réponses divergentes.

Une attente sans origine observable

Le projet combine le modèle 2 de RFC 8901 avec les signaux enfant-parent de CDS/CDNSKEY et CSYNC. Chaque opérateur conserve ses propres clés, mais tous doivent publier une vue compatible de l’infrastructure de la zone. Cette séparation évite de confier toutes les clés privées à un seul fournisseur. Elle rend aussi visible une chaîne d’autorité que les tableaux de bord résument trop facilement par « migration terminée ».

Dans cette chaîne, l’enfant exprime une intention, le parent applique sa politique et publie, les autorités servent, les caches vieillissent, les résolveurs valident et l’application observe un résultat. Le contrôleur peut ordonner ces étapes. Il ne peut pas transférer la preuve d’une étape à la suivante.

Le DS-Wait-Time illustre le problème. Le projet le fait commencer après la publication du nouvel ensemble DS par le parent. Le minimum est le TTL du DS. L’envoi de CDS, la détection par un scanner parental et l’acceptation par un système de registre ne sont pas cette publication. Si l’horloge part plus tôt, une partie du délai protège du temps où le nouvel état n’existait pas encore.

Un reçu défendable nomme donc le RRset observé, l’autorité interrogée, l’heure, le TTL, l’état de validation et le point de vue. Le calcul vient ensuite. Dormir longtemps à partir d’un instant inconnu ne crée pas une marge de sécurité mesurable.

Quatre horloges, quatre objets

DNSKEY-Wait-Time protège la diffusion du nouvel ensemble de clés. Son minimum inclut le plus grand TTL DNSKEY des signataires et le temps nécessaire à la publication sur toutes les secondaires. Une écriture réussie sur le primaire n’atteste ni les secondaires ni les réponses réellement servies.

NS-Wait-Time protège la transition de joignabilité. Il se calcule à partir des TTL NS du parent et des signataires après publication parentale. Un CSYNC correct est une demande structurée, pas la mutation du parent. Même un accusé de réception de registre reste un reçu de processus.

RRSIG-Wait-Time protège les données encore signées par une ancienne clé. Quand un signataire cesse de signer, sa clé doit rester publiée jusqu’à ce que les signatures antérieures puissent quitter les caches. L’arrêt d’un job de rollover n’est pas l’expiration de ces signatures.

Ces délais ne sont pas interchangeables. Le DS concerne le lien de confiance parental ; DNSKEY, la disponibilité des clés ; NS, le chemin vers les autorités ; RRSIG, les objets signés encore acceptables. Un voyant vert commun détruit précisément la distinction nécessaire au diagnostic.

Rejoindre exige une vue de groupe

Un nouveau signataire doit déjà servir une zone fonctionnelle et signer avec des algorithmes compatibles. Les participants doivent distinguer leurs clés de celles des autres et leurs propres NS de ceux introduits pour le groupe. Sans cette provenance, le retrait futur devient une opération à l’aveugle.

Le groupe distribue les clés publiques de signature de données, compile un ensemble CDS/CDNSKEY couvrant tous les KSK ou CSK, puis attend le DS combiné du parent. Il prépare ensuite l’ensemble NS commun et peut utiliser CSYNC pour demander la projection parentale.

La réussite locale d’un signataire ne ferme jamais le groupe. Il faut comparer les RRsets de chacun, constater la publication parentale et conserver le désaccord éventuel. Choisir le premier répondant ou le délai le plus court transformerait la diversité des fournisseurs en course vers l’état le moins prouvé.

Sortir détruit les chemins de secours

La sortie est plus risquée que l’entrée. Le projet retire d’abord les NS du signataire sortant chez les participants restants et au parent, attend la fin de l’exposition NS, puis autorise l’ancien fournisseur à cesser de répondre. Ensuite seulement viennent le retrait de ses clés des signaux parentaux, l’attente des anciennes signatures et la suppression finale de la clé publique.

Deux questions restent séparées : les requêtes peuvent-elles encore atteindre l’ancien serveur, et les caches peuvent-ils encore présenter des données signées par son ancienne clé ? NS-Wait-Time répond à la première sous ses hypothèses. RRSIG-Wait-Time répond à la seconde. Aucun ne prouve que le contenu des autres serveurs est identique.

La date de fin d’un contrat ne connaît pas ces dépendances. Si elle coupe le service trop tôt, la séquence protocolaire casse. Si l’entreprise prolonge silencieusement le chevauchement, coût, responsabilité et accès restent indéfinis. La gouvernance doit décider qui peut retarder la sortie et quel reçu libère l’opérateur sortant.

Des clés identiques, des zones différentes

Le projet exclut la synchronisation du contenu général de la zone. Il coordonne les enregistrements d’infrastructure, mais ne définit pas le transport des données applicatives entre fournisseurs.

Trois autorités peuvent donc exposer les mêmes DNSKEY et NS tout en servant des générations différentes de la zone. Chaque réponse peut être correctement signée. L’une peut contenir un nom que l’autre nie, ou une secondaire peut avoir un SOA ancien. DNSSEC authentifie la réponse selon ses règles ; il ne détermine pas quelle copie représente l’intention la plus récente du propriétaire.

Une migration a besoin d’un second contrat : transfert de zone autorisé, génération ou série attendue, comparaison de contenu, cohérence des politiques de signature et sondage de chaque autorité. « Groupe multi-signataire formé » ne doit pas devenir « contenu convergé » sans ce reçu.

Centraliser ou distribuer ne supprime pas l’autorité

Dans le modèle centralisé, un contrôleur calcule les délais et agit sur tous les signataires. Il peut produire un journal cohérent, mais concentre les identifiants et l’erreur. Un contrôleur périmé ou trop puissant déplace tout le groupe vers un état faux.

Dans le modèle décentralisé, chaque signataire calcule à partir des informations reçues. La concentration diminue, mais les vues peuvent diverger. Un participant utilisant un TTL ancien ou une observation parentale différente peut avancer localement de manière correcte et collectivement dangereuse.

Le « mécanisme de confiance » capable de modifier DNSKEY, CDS/CDNSKEY, CSYNC et NS est lui-même hors périmètre détaillé du projet. Il doit pourtant avoir un principal, un champ d’action, des identifiants révocables et un journal. Une machine d’état parfaite pilotée par la mauvaise identité reste une erreur d’autorité.

Le statut du texte borne le constat

Au gel des preuves, Datatracker qualifie la révision 05 de document DNSOP actif, en attente du feu vert du président. Il indique un statut prévu Informational. L’en-tête dit Standards Track et fixe l’expiration au 6 janvier 2027. Cette divergence documentaire doit rester visible.

Elle ne prouve ni consensus achevé, ni publication RFC, ni prise en charge logicielle. Les références à des implémentations ne démontrent pas une adoption ou une interopérabilité en production. Aucun élément du dossier ne documente un fournisseur, une migration, une panne ou une performance mesurée. Le cas d’ouverture est analytique.

Le produit durable est le journal de transition

Pour chaque étape, le journal devrait conserver la zone, la génération du groupe, le participant, le RRset attendu et observé, le point de vue autoritatif, le TTL, l’heure, le statut de validation, la politique, le prochain instant possible et le principal ayant autorisé l’action.

Les intentions enfant, publications parentales, horizons de cache, sorties de signataires, validations résolveur et résultats applicatifs doivent rester des lignes différentes. Une inconnue ne devient pas zéro. Si la publication de toutes les secondaires n’est pas observable, le début de DNSKEY-Wait-Time est incertain. Le journal doit le dire et bloquer la transition.

La promesse raisonnable du projet est étroite : ordonner des obligations et fixer des délais minimaux pour une transition DNSSEC multi-signataire. Il ne prouve pas l’état de tous les caches, la synchronisation du contenu, la réponse de chaque résolveur ou la réussite du service. Ces conclusions ont besoin de leurs propres observateurs.

Sources