Résumé

  • Un renouvellement DNSSEC fait passer les clés par plusieurs états; il ne se résume pas à l’heure d’une cérémonie.
  • La diffusion sur les serveurs faisant autorité, l’expiration des caches, le DS parent et l’attente des ancres de confiance suivent des horloges distinctes.
  • L’ancien matériel doit rester disponible tant qu’une combinaison de validation encore plausible en dépend.
  • Un dossier de suivi du renouvellement doit encadrer activation, retrait et suppression.

Imaginons une cérémonie planifiée qui se termine sans alerte. La nouvelle DNSKEY est publiée, le signataire produit des signatures valides et le tableau de contrôle affiche un succès. L’ancienne clé est retirée à l’heure prévue. Peu après, un groupe de clients utilisant des résolveurs validateurs reçoit des réponses SERVFAIL, alors que les sondes proches des serveurs faisant autorité restent au vert.

La cryptographie n’a pas changé entre les deux observations. L’exploitation a simplement confondu plusieurs horloges avec celle de la cérémonie.

RFC 7583 décrit le renouvellement comme une progression chronométrée entre des états: générée, publiée, prête, active, retirée, morte puis supprimée. Une clé peut être visible sans être prête, active sans être exploitable par tous les résolveurs, ou retirée alors que des données en cache en ont encore besoin. La sûreté consiste à maintenir au moins un chemin de validation cohérent pendant l’évolution des ensembles DNSKEY, RRSIG et, pour une KSK, DS.

La première horloge mesure la diffusion sur les serveurs faisant autorité. Publier une clé sur le serveur principal ne la place pas instantanément sur tous les serveurs. RFC 7583 intègre le délai de propagation à l’intervalle précédant l’état prêt. RFC 6781 applique ce principe au pré-déploiement d’une ZSK: introduire la nouvelle DNSKEY, la diffuser sur tous les serveurs faisant autorité, puis la conserver pendant le TTL de l’ensemble avant de signer les données de production avec elle.

La deuxième horloge appartient aux caches. Un validateur peut garder un ancien ensemble DNSKEY tout en récupérant une RRSIG récente, ou conserver une ancienne signature en rafraîchissant les clés. La méthode choisie doit rendre ces combinaisons compatibles. Avec la prépublication, la nouvelle clé attend avant son activation et l’ancienne subsiste après le changement de signatures. Avec la double signature, les deux générations se chevauchent, au prix de réponses plus volumineuses.

La troisième horloge se trouve chez le parent. Le renouvellement d’une ZSK peut rester interne à la zone. Celui d’une KSK relie normalement la DNSKEY enfant au DS publié par la zone parente. Une preuve de soumission au registre n’est pas une preuve de publication DNS. Il faut observer le nouveau DS, attendre l’expiration de l’ancien dans les caches et conserver le chemin précédent tant que son successeur n’est pas établi.

La quatrième horloge concerne les résolveurs qui gèrent une ancre de confiance selon RFC 5011. Une nouvelle clé SEP entre d’abord en attente. Le résolveur laisse expirer le délai d’ajout, puis récupère et valide un nouvel ensemble DNSKEY qui contient encore la clé. Le délai vaut trente jours ou l’expiration du TTL initial si elle est plus longue. Pour la suppression, une ancre n’atteint l’état Removed qu’après les observations de révocation ou d’absence prévues; son état est ensuite conservé trente jours avant l’effacement du suivi interne. Cette conservation concerne l’état de l’ancre dans le résolveur et ne constitue pas un délai général autorisant le retrait d’une DNSKEY de la zone. Cette horloge réside dans l’état du validateur, hors du contrôle direct de la zone.

Ces horloges ne sont pas quatre affichages d’un même compte à rebours. Elles commencent sur des événements différents, appartiennent à des acteurs différents et attestent des transitions différentes. La seule présence de la clé ne permet pas d’autoriser son activation. Une signature valide depuis un point de mesure ne permet pas de supprimer l’ancienne clé. Un reçu du portail parent ne ferme pas les caches. Trente jours écoulés ne prouvent pas la nouvelle observation exigée par RFC 5011.

Le bon objet de preuve est un dossier de suivi du renouvellement. Il nomme la zone, la méthode, les identifiants de clés et les algorithmes. Il conserve les passages d’état, les observations DNSKEY, RRSIG et DS depuis des points nommés, les TTL, les bornes de propagation et de validité des signatures. Il distingue soumission, visibilité sur les serveurs faisant autorité et échéance de cache.

Pour les populations RFC 5011, il conserve le point de confiance, la première observation validée, l’échéance d’attente et l’observation ultérieure qui achève l’acceptation. Pour toutes les populations, il enregistre les résultats de validation par groupes de résolveurs. Chaque transition possède un responsable, une preuve requise et une limite de retour arrière.

La formulation de l’achèvement devient alors précise. «La cérémonie a eu lieu» décrit une action de gestion. «La nouvelle clé est active» décrit un état compatible selon la méthode choisie. «L’ancienne clé peut être supprimée» signifie que plus aucun état plausible de cache ou d’ancre n’en dépend. Ces phrases peuvent porter des dates proches; elles ne disent pas la même chose.

Sources

RFC 7583 — calendrier des renouvellements de clés DNSSEC; RFC 6781 — pratiques opérationnelles DNSSEC; RFC 5011 — mise à jour automatisée des ancres DNSSEC.