Résumé

  • Une zone pré-signée et des RRSIG non expirés peuvent maintenir temporairement la validation après qu’une clé privée est devenue inutilisable. Ils ne restaurent pas la clé et ne prouvent ni la disponibilité d’une nouvelle capacité de signature, ni la convergence des caches, ni la continuité du service.
  • Le chemin praticable dépend du rôle de la clé : prépublication pour une ZSK perdue alors que la KSK reste utilisable ; Double-DS pour une KSK perdue ; Double-DS ajusté et période de retrait plus longue pour une CSK perdue.
  • La restauration n’est établie qu’en reliant des observations distinctes : conservation de l’ancien état, publication et activation du nouveau matériel, propagation du DS parent, chargement par chaque serveur faisant autorité, cohérence SOA/NSEC/NSEC3/ZONEMD, validation par des résolveurs indépendants et tests applicatifs pendant toute la période de chevauchement.

Le calme est un compteur, pas un verdict

Le premier incident visible peut être l’absence d’incident. La partie privée d’une DNSKEY cesse de fonctionner — support matériel hors service, accès perdu, sauvegarde inexploitable — mais les serveurs faisant autorité continuent de répondre avec une zone correctement signée. Les signatures ont été produites avant la panne et leurs dates d’expiration sont encore éloignées. Un résolveur validant peut donc retourner « Secure ». Le site répond, le courrier circule et les tableaux de supervision restent verts.

Ce calme a une nature précise : les serveurs récitent un état cryptographique antérieur. Il ne démontre pas que la clé privée existe encore, qu’un seul octet pourrait être signé à nouveau, ni qu’un changement de zone serait sûr. Si aucune sauvegarde opérationnelle de la clé privée n’existe, la clé n’est pas récupérable. Ce qui peut être restauré est la fonction de signature de la zone, au moyen d’une nouvelle clé et d’une transition dont chaque délai est respecté.

C’est la distinction centrale de draft-ietf-dnsop-dnssec-keyrestore-02. Au moment de la présente vérification, le document est un Internet-Draft actif du groupe de travail DNSOP, révision 02, mis à jour le 10 août 2026. Il s’agit d’un travail en cours à vocation informative, pas d’un RFC. Son périmètre couvre les architectures où les enregistrements sont pré-signés ; la signature en ligne est exclue. La zone racine est également exclue, car la distribution d’une nouvelle ancre de confiance peut durer plus longtemps que la validité des RRSIG. Le terme « inutilisable » désigne ici une partie privée qui ne peut plus signer ; une clé compromise mais encore techniquement utilisable pose un autre problème et exige une réponse de sécurité différente.

Ce que l’ancien état achète — et ce qu’il n’achète pas

Une copie complète de la dernière zone signée, éventuellement récupérée depuis un serveur faisant autorité, est le capital initial de la restauration. Sa valeur décroît avec chaque seconde. La limite extérieure est l’expiration des RRSIG ; à l’intérieur se trouvent les TTL restant dans les caches et les délais de propagation vers les instances faisant autorité. L’opérateur peut encore raccourcir la fenêtre en supprimant trop tôt une ancienne DNSKEY ou ses signatures, ou en modifiant un RRset que l’ancienne clé ne peut plus signer.

Le signataire ne doit donc pas retirer les DNSKEY tant qu’une instruction explicite ne le permet pas, et devrait conserver les anciens RRSIG. Si le logiciel ne sait pas préserver ces signatures, toutes les anciennes signatures, hormis celle qui couvre l’ancien RRset DNSKEY, doivent être restaurées manuellement avant publication. Introduire simultanément un nouvel algorithme élargirait inutilement le nombre de variables : sauf si un changement d’algorithme était déjà engagé, la priorité consiste à rétablir la fonction avec l’algorithme actuel, puis à effectuer plus tard un changement ordinaire.

Cette discipline découle du modèle d’états décrit par le RFC 7583 — publié, prêt, actif, retiré, mort — et des mécanismes opérationnels du RFC 6781. Une clé visible n’est pas nécessairement prête ; une clé prête n’est pas nécessairement active ; une clé retirée localement n’est pas forcément devenue sans objet pour tous les caches. La restauration échoue lorsque ces verbes sont traités comme des synonymes.

Huit observations, huit portées différentes

Une ancienne DNSKEY accompagnée d’un RRSIG non expiré sur un serveur prouve que ce serveur expose, à cet instant, un état ancien vérifiable selon les règles des RFC 4034 et RFC 4035. Elle ne prouve pas que la clé privée subsiste, que la nouvelle signature fonctionne, que tous les serveurs servent le même contenu ou qu’un résolveur possède une chaîne complète.

Une nouvelle DNSKEY vue sur une instance ne prouve que sa publication à ce point d’observation. Les autres instances, les nœuds anycast et les secondaires peuvent encore servir l’ancienne version ; des résolveurs peuvent conserver l’ancien RRset DNSKEY jusqu’à la fin de son TTL. De même, l’acceptation administrative d’un nouveau DS par un bureau d’enregistrement ou un registre ne prouve pas sa publication dans la zone parente, encore moins sa présence sur chaque serveur parent ou l’écoulement de TTLds dans les caches.

Un nouveau RRSIG qui valide avec la nouvelle clé fournit une preuve forte, mais étroite : un RRset, une signature, une clé et un instant. Il ne dit pas que tous les RRsets ont été resignés. Il ne certifie ni la cohérence des réponses négatives, ni celle de ZONEMD, ni le droit de retirer l’ancien chemin. Un numéro de série SOA identique est un indice utile de version ou de transfert, pas une empreinte cryptographique de tout le contenu. Une réponse NSEC ou NSEC3 valide montre qu’une preuve de non-existence fonctionne, pas que tous les noms, bitmaps de types et serveurs sont cohérents.

ZONEMD ajoute une preuve d’intégrité du contenu selon son propre mécanisme, à condition que le condensat ait été régénéré pour la zone modifiée et que le RRSIG qui le couvre valide. Le RFC 8976 montre pourquoi la génération du condensat, sa signature et la construction de NSEC/NSEC3 forment une séquence ordonnée. ZONEMD ne remplace toutefois ni la validation de la chaîne DNSSEC ni l’observation du service en production.

Enfin, un résolveur validant qui répond « Secure » ne parle que pour son chemin et son état de cache. Une requête HTTP ou TLS réussie ne parle que pour un parcours applicatif. Aucun de ces résultats isolés n’établit une convergence mondiale, l’intégrité de toutes les instances faisant autorité ou l’absence d’impact pour tous les utilisateurs.

ZSK perdue, KSK disponible : publier avant d’activer

Dans une architecture à clés séparées, si la ZSK est inutilisable mais que la KSK fonctionne encore, la zone ne peut d’abord pas changer : les données existantes ne pourraient plus recevoir de nouvelles signatures de la ZSK perdue. Le seul chemin adapté est la prépublication.

À Tpub, l’opérateur ajoute la nouvelle ZSK au RRset DNSKEY, conserve l’ancienne ZSK inutilisable et tous ses RRSIG, et fait signer le RRset DNSKEY par la KSK toujours disponible. Il évite normalement de changer le SOA à ce stade et force le chargement par les secondaires. La nouvelle clé ne devient prête qu’à Trdy = Tpub + Ipub, avec Ipub = Dprp + TTLkey. Dprp représente le temps nécessaire pour que toutes les instances faisant autorité reçoivent l’état ; TTLkey, le temps maximal pendant lequel un résolveur peut conserver l’ancien RRset DNSKEY.

Après Trdy, la zone peut changer et être signée avec la nouvelle ZSK. Les anciens RRSIG peuvent alors être supprimés, mais l’ancienne ZSK doit rester publiée. Son retrait n’est sûr qu’après Iret = Dsgn + Dprp + TTLsig, qui couvre le délai de signature, la propagation faisant autorité et le TTL maximal des RRSIG. La variante théorique à double signature est plus lente dans cette urgence, car les données resteraient figées jusqu’à Dsgn + Dprp + max(TTLkey, TTLsig).

La preuve attendue n’est donc pas une capture unique de la nouvelle DNSKEY. Il faut des observations par instance à Tpub, des preuves de chargement, puis l’écoulement documenté de TTLkey, des RRSIG nouvellement produits sur les RRsets et, enfin, l’écoulement de l’intervalle de retrait avant de supprimer l’ancienne clé.

KSK perdue : le parent détient l’horloge décisive

Si la KSK est inutilisable, elle ne peut plus signer un RRset DNSKEY modifié. La prépublication enfant ne suffit pas. Le chemin disponible est Double-DS. Si la ZSK est également inutilisable, la fonction KSK doit être restaurée en premier ; tenter les deux transitions à la fois supprimerait les points d’appui qui rendent l’ordre démontrable.

Le nouveau DS est soumis au parent à Tsbm. Après le délai d’enregistrement Dreg, il est publié à Tpub. Ces deux événements doivent rester distincts dans les preuves : un reçu du registraire ne vaut pas observation DNS. Une fois le DS visible, il faut attendre IpubP = DprpP + TTLds, somme de la propagation vers toutes les instances du parent et du TTL du DS. Ce n’est qu’à Trdy = Tpub + IpubP que la nouvelle KSK est prête.

À l’activation, la nouvelle KSK entre dans le RRset DNSKEY enfant et le signe. L’ancienne KSK inutilisable peut quitter ce RRset, tandis que la ZSK reste en place. Si cette ZSK est elle aussi inutilisable, le SOA est préservé, les secondaires sont forcés de charger l’état KSK, puis la procédure de prépublication ZSK commence. L’ancien DS parent doit rester pendant Iret = DprpC + TTLkey après l’activation, afin que les résolveurs qui détiennent encore un ancien RRset DNSKEY enfant puissent valider. Le moment le plus tôt pour retirer l’ancien DS est donc Trem = Tact + Iret.

Le RFC 8078 et son successeur RFC 10026 encadrent l’automatisation par CDS/CDNSKEY et les enregistrements de décision. Mais après la perte d’une KSK ou d’une CSK, surtout si la ZSK ou la CSK ne peut plus signer, un changement manuel du parent peut être indispensable. Un CDS/CDNSKEY nouvellement ajouté ne peut pas être validé cryptographiquement ; ajouter ces types modifie aussi le bitmap de types NSEC/NSEC3 à l’apex, que la clé perdue ne peut pas re-signer. L’automatisation habituelle ne constitue donc pas, à elle seule, une voie de secours.

CSK perdue : un seul secret, deux dépendances

Une CSK signe à la fois le RRset DNSKEY et les données de la zone. Sa perte réunit les contraintes de la KSK et de la ZSK. Le chemin est un Double-DS ajusté : publication du nouveau DS au parent, attente de Dreg, puis de IpubP = DprpP + TTLds, avant toute activation enfant.

À l’activation, la nouvelle CSK est ajoutée et signe le RRset DNSKEY. L’ancienne CSK inutilisable ainsi que tous ses RRSIG restent en place. L’opérateur évite un changement SOA dangereux et force les secondaires à charger la zone. La période de retrait est plus longue : Iret = Dsgn + DprpC + max(TTLkey, TTLsig). Ce n’est qu’à Trem = Tact + Iret que l’ancien DS parent, l’ancienne CSK et les anciennes signatures peuvent être retirés ensemble, et que les changements normaux de zone peuvent reprendre.

Cette simultanéité finale est importante. Retirer seulement le DS ancien, ou seulement l’ancienne CSK, en se fondant sur une validation positive récente peut rompre le chemin d’un résolveur dont le cache se trouve à une autre étape. Le chevauchement est une propriété de l’ensemble, pas de chaque enregistrement pris séparément.

Ne pas transformer la restauration en divergence silencieuse

La contrainte la moins intuitive concerne le SOA. Pour restaurer une ZSK ou une CSK inutilisable, le brouillon recommande de ne pas changer le SOA uniquement afin d’introduire la nouvelle DNSKEY. L’ancienne clé ne pourrait pas signer ce SOA modifié. Les réponses sur des RRsets existants pourraient encore valider, alors que les preuves de non-existence pour des types absents deviendraient « Bogus ». Préserver le SOA protège l’état signé, mais retire au mécanisme habituel fondé sur le numéro de série une partie de sa capacité à déclencher la convergence.

Les secondaires qui dépendent d’IXFR ou d’AXFR doivent alors parfois être forcés manuellement à charger la nouvelle version. Les mécanismes de notification et de transfert décrits par les RFC 1996 et RFC 9103 fournissent des moyens de transport et de signalement ; ni une notification envoyée, ni un transfert demandé, ni un même numéro de série ne prouve que chaque secondaire sert les octets attendus.

Le changement du RRset DNSKEY rend également caduc un condensat ZONEMD publié. Il faut régénérer ZONEMD, le signer et reconstruire correctement la chaîne avec NSEC/NSEC3. Le brouillon rapporte une vérification des procédures avec Knot DNS, tout en signalant des étapes manuelles et l’absence de prise en charge, dans le chemin testé, de la génération manuelle d’un nouveau condensat ZONEMD. C’est la preuve d’un exercice sur une mise en œuvre, non celle d’un support universel.

Une chaîne de preuves avant le mot « restauré »

Le dossier minimal commence par une capture immuable de la dernière bonne zone signée : inventaires DNSKEY et DS, dates de début et d’expiration des RRSIG, SOA, NSEC ou NSEC3 et ZONEMD. Il se poursuit par des observations de chaque instance faisant autorité — y compris, dans la mesure du possible, les composants derrière l’anycast — montrant à la fois la conservation de l’ancien état et l’arrivée du nouveau.

Côté parent, les preuves séparent la demande de DS, son acceptation, sa publication sur les serveurs faisant autorité et l’écoulement du TTL. Côté enfant, elles séparent publication, préparation, activation, nouvelle signature complète des RRsets, propagation et retrait. Les reçus de chargement ou de transfert couvrent tous les secondaires ; les contrôles confrontent SOA, réponses positives, preuves négatives et ZONEMD.

Des résolveurs récursifs exploités indépendamment sont ensuite interrogés depuis plusieurs réseaux. Les contrôles associent caches chauds et froids, réponses positives et négatives, RRsets DNSKEY et DS, durées de vie des RRSIG, et observations répétées jusqu’au-delà de la fenêtre de retrait. Vider le cache d’un seul résolveur et observer « Secure » ne représente pas Internet. Des tests applicatifs depuis plusieurs réseaux doivent enfin durer pendant tout le chevauchement et le retrait : ils mesurent la continuité vécue, sans être confondus avec une preuve cryptographique.

Les équations offrent des bornes conservatrices seulement si les délais de propagation et les TTL maximaux sont connus et si la publication est effectivement observée. Les caches mondiaux ne sont pas dénombrables. L’assurance repose donc sur un faisceau temporel d’observations indépendantes, assorti de points d’arrêt explicites : tant qu’une preuve nécessaire dépend encore de l’ancien DS, de l’ancienne DNSKEY ou d’anciens RRSIG, rien de cet ancien chemin ne doit disparaître.

Sources