Résumé

  • draft-ietf-dnsop-dnssec-keyrestore-02 traite le cas où une clé privée devient inutilisable sans sauvegarde exploitable, tandis qu’une copie complète et encore valide de la zone présignée demeure disponible.
  • La continuité dépend alors de délais distincts : expiration des RRSIG, diffusion de la nouvelle DNSKEY, publication du DS par le parent, chargement des secondaires et vidage prudent des caches.
  • Un reçu des horloges de reprise devrait attribuer à chaque transition son responsable, son calcul et sa preuve. Cette proposition appartient à l’analyse de Daniel Kade, pas au texte normatif de DNSOP.

La première erreur serait de déclarer la panne inexistante parce que le nom se résout. La seconde serait de modifier précipitamment la zone comme si la chaîne de signature fonctionnait encore normalement. Entre ces deux erreurs se trouve une période utile, mais finie : les données déjà signées restent vérifiables, tandis que la production de nouvelles signatures est impossible.

La révision 02 de DNSSEC Key Restore a été publiée le 10 août 2026. C’est un Internet-Draft actif du groupe DNSOP, présenté comme Informational dans le document rendu. Il peut encore évoluer, être remplacé ou expirer. Ce n’est ni un RFC, ni une BCP, ni un engagement de service de RIPE NCC, organisme auquel les deux auteurs sont affiliés. Le texte vise les zones présignées ; la signature en ligne et la zone racine sont hors périmètre.

Le verbe « restaurer » doit lui aussi être borné. La procédure ne ressuscite pas une clé privée disparue. Elle rétablit la fonction de signature avec une nouvelle clé, en gardant assez longtemps les données publiques de l’ancienne pour que les validateurs ne rencontrent pas une combinaison impossible.

Une continuité sans capacité de changement

Le projet qualifie d’inoperable la partie privée qui ne peut plus signer. Une panne matérielle, une catastrophe, une erreur d’exploitation ou une action malveillante peuvent produire cet état. Une clé compromise mais encore capable de signer appartient à une autre catégorie. La première question est la continuité ; la seconde ajoute un adversaire possible. Les confondre rend la procédure et les pouvoirs d’exception inadaptés.

Au moment de la défaillance, les serveurs autoritatifs peuvent encore distribuer une zone correctement signée. Les RRSIG ont souvent une durée de validité de plusieurs jours. Cette observation ne promet aucun délai standard : le temps réellement disponible est fixé par les dates d’expiration des signatures présentes, par les RRsets concernés et par les versions déjà conservées dans les caches.

La zone paraît stable, mais elle peut être gelée. Corriger une adresse, retirer un service compromis, déplacer le courrier ou publier une nouvelle preuve suppose de signer les RRsets modifiés. L’ancien contenu continue donc à fonctionner précisément parce qu’il n’a pas changé. La disponibilité observable ne prouve pas la capacité à agir.

Le projet demande de conserver les DNSKEY et RRSIG anciens. Un logiciel de signature ne doit pas supprimer automatiquement une clé publique au seul motif que la partie privée manque. Si l’outil élimine les anciennes signatures, l’opérateur peut devoir les remettre manuellement. Ces objets ne servent plus à produire l’avenir, mais ils soutiennent encore le présent.

Trois rôles de clé, trois géographies de pouvoir

La perte d’une ZSK n’emprunte pas le même chemin que celle d’une KSK ou d’une CSK. Avec une ZSK inutilisable et une KSK disponible, l’opérateur peut insérer une nouvelle ZSK dans le RRset DNSKEY, que la KSK opérationnelle sait encore signer. La simple présence sur le primaire ne suffit pas. La clé devient prête après le délai de propagation autoritative et le TTL de DNSKEY : Ipub = Dprp + TTLkey.

La nouvelle ZSK peut alors signer la zone. L’ancienne reste publiée jusqu’à ce que la nouvelle signature soit terminée, que le contenu soit diffusé et que les RRSIG historiques aient disparu des caches. Le projet exprime ce second délai par Iret = Dsgn + Dprp + TTLsig. Détection, publication, activation et retrait ne sont pas une seule opération.

Si la KSK est perdue mais que la ZSK fonctionne, la confiance doit passer par le parent. La méthode Double-DS commence par la soumission d’un nouveau DS. Sa publication intervient après le délai d’enregistrement, Tpub = Tsbm + Dreg. Il faut ensuite attendre la propagation chez le parent et le TTL du DS, IpubP = DprpP + TTLds, avant d’activer la KSK de remplacement dans l’enfant.

Ce délai appartient en partie au registre, au bureau d’enregistrement ou à l’opérateur du parent. RFC 7583 souligne déjà que le gestionnaire de la zone ne maîtrise pas entièrement le calendrier d’une KSK dépendante du parent. Un accusé de réception d’API n’est donc ni la publication du DS, ni sa disponibilité dans les caches.

La perte d’une CSK cumule les dépendances. La même clé portait la signature du RRset DNSKEY et celle des autres données. Le nouveau DS doit d’abord franchir le parent ; la zone doit ensuite retrouver sa capacité de signature. Les anciennes signatures et l’ancienne clé restent nécessaires pendant une période de retraite qui inclut la signature, la propagation enfant et le plus grand des TTL de DNSKEY et de RRSIG.

Quand l’automatisation redevient une procédure humaine

En régime normal, CDS et CDNSKEY peuvent demander automatiquement une modification du DS chez le parent. Or une ZSK ou une CSK inutilisable ne peut pas signer correctement les nouveaux enregistrements qui porteraient cette demande. Le projet impose alors une mise à jour manuelle du DS. La défaillance cryptographique révèle ainsi une chaîne institutionnelle : identifier l’organisation autorisée, vérifier le nouveau matériel, accepter une exception et prouver que le parent a réellement publié le résultat.

Les secondaires forment une autre couture. Pour ne pas modifier un SOA que l’ancienne clé ne sait plus signer, l’opérateur peut garder le SOA inchangé lors de l’ajout de la DNSKEY. Mais IXFR et AXFR peuvent alors ne pas déclencher le chargement attendu. Chaque secondaire concerné doit parfois être forcé à charger la version modifiée. Une réponse correcte du primaire ne suffit pas à certifier l’ensemble du service autoritatif.

ZONEMD complique encore l’état. Une modification du RRset DNSKEY rend le condensat précédent caduc. Il faut en produire et signer un nouveau. La section d’implémentation consacrée à Knot DNS signale que la génération manuelle de ce condensat n’est pas prise en charge dans la procédure décrite. C’est une limite opérationnelle utile, non une comparaison exhaustive des logiciels.

Lors de l’IETF 126, un participant a demandé de mieux confronter TTL et échéance des signatures ; un autre a réclamé des essais sur les signataires. Le présentateur a indiqué un fonctionnement avec Knot DNS et la présidence a demandé une section d’implémentation. Ces minutes expliquent l’évolution de la révision, mais ne démontrent ni interopérabilité générale ni déploiement courant.

Le reçu des horloges de reprise

Un rapport d’incident réduit souvent l’histoire à « début » et « rétablissement ». Ici, ce raccourci efface les décisions les plus risquées. Le reçu proposé commence par la qualification de la panne, le rôle de la clé et l’algorithme. Il calcule la première échéance critique parmi les signatures réellement servies, au lieu de reprendre une durée configurée en théorie.

Il conserve ensuite la preuve que l’ancienne DNSKEY et les RRSIG nécessaires restent disponibles. Il note l’apparition de la nouvelle clé sur les instances autoritatives, la propagation mesurée, les TTL utilisés et le moment où la clé peut être considérée prête.

Pour une KSK ou une CSK, soumission au parent, authentification, acceptation, publication observée et fin de l’horizon de cache occupent cinq cases différentes. Pour les secondaires, le reçu nomme les cibles rechargées et le contenu observé. Pour ZONEMD, il précise si le nouveau condensat existe ou quelle autorité a accepté son absence temporaire.

La fin du reçu sépare la nouvelle signature, son contrôle par échantillon, l’éligibilité au retrait des anciens objets et leur suppression effective. Chaque manipulation manuelle reçoit un décideur et une voie de correction. Aucune clé privée ni configuration sensible de HSM n’a besoin d’être publiée : les empreintes d’artefacts, key tags, dates, versions de politique et rôles organisationnels suffisent à rendre la séquence vérifiable.

Une preuve honnête à propos des caches

Personne n’observe tous les résolveurs récursifs. Les TTL permettent d’établir un horizon prudent, pas de certifier que chaque cache mondial s’est vidé. Des sondes distribuées peuvent confirmer plusieurs chemins autoritatifs et récursifs ; elles restent des échantillons.

Cette limite renforce l’utilité des paramètres. Avec Dprp, TTLkey, TTLds, TTLsig et le délai de signature, un tiers peut vérifier le raisonnement temporel. Un voyant vert sans valeurs d’entrée transforme un calcul de sûreté en affirmation administrative.

Le vocabulaire doit rester aussi précis que les chiffres. Une demande peut être soumise sans être acceptée, acceptée sans être publiée, publiée sans être prête dans les caches, prête sans être active, active alors que l’ancien matériel ne peut pas encore être retiré. Le mot « rétabli » ne devrait arriver qu’après ces distinctions.

Le projet fournit une procédure technique crédible pour préserver la validation pendant la reconstruction de la fonction de signature. Il ne fournit pas un SLA universel, une promesse du parent, un format d’audit ni une vue exhaustive des caches. Son apport de gouvernance est ailleurs : la durée résiduelle des signatures est un budget collectif. La reprise devient responsable lorsque chaque horloge est reliée à l’acteur qui peut la faire avancer et à la preuve qu’elle a effectivement avancé.

Sources

  1. DNSSEC Key Restore — révision 02
  2. Fiche Datatracker du projet
  3. Historique du document
  4. Compte rendu DNSOP de l’IETF 126
  5. Documents actifs de DNSOP
  6. Charte de DNSOP
  7. RFC 9364 : DNS Security Extensions
  8. RFC 7583 : calendrier des rotations de clés DNSSEC
  9. RFC 8078 : gestion des DS par CDS/CDNSKEY
  10. RFC 8976 : condensat de zone DNS
  11. RFC 9499 : terminologie DNS