Résumé

  • L’incident .de du 5 mai 2026 n’est pas un récit général sur la fragilité d’Internet, mais un cas précis de défaillance d’état signé dans une infrastructure DNSSEC: une opération routinière de rotation de clé ZSK a conduit à des signatures dont la validation dépendait du HSM qui les avait produites, alors qu’une seule clé publique DNSKEY correspondante était publiée dans la zone.
  • La leçon opérationnelle est que l’anycast, les sites multiples et les HSM multiples ne suffisent pas à préserver la disponibilité si le matériau cryptographique partagé est incohérent; la continuité d’un registre dépend aussi de la parité entre tests et exploitation réelle, du blocage de mise en ligne, de l’attribution des alertes, du retour arrière et de la vérification externe.

Le 5 mai 2026, le registre allemand DENIC a connu une perturbation DNSSEC qui a affecté la résolution de noms sous .de pendant la soirée et le début de la nuit suivante. La chronologie publique doit être tenue avec précision, car elle porte déjà une partie de l’analyse de responsabilité. Dans son avis de résolution, DENIC situe l’impact perceptible à partir de 21 h 57 le 5 mai, indique que la distribution d’une zone correcte a commencé à 00 h 08 le 6 mai et déclare que l’état de fonctionnement précédent a été rétabli à 01 h 15. Cloudflare, de son côté, a décrit des défaillances de validation visibles plus tôt dans sa télémétrie de résolveur.

Ces deux horloges ne mesurent pas exactement la même chose. L’une décrit la chronologie opérationnelle formelle du registre; l’autre décrit ce qu’un grand résolveur récursif a observé depuis son propre point de vue. Les fusionner en un unique début mondial serait une simplification trompeuse.

L’événement a eu lieu pendant une rotation DNSSEC routinière sur le domaine de premier niveau .de. DNSSEC ajoute au DNS une chaîne d’authentification: un résolveur qui valide ne se contente pas de recevoir un enregistrement, il vérifie aussi que la réponse peut être reliée à des clés publiées et à des signatures cohérentes. Dans cette chaîne, la ZSK, ou Zone Signing Key, sert à signer les ensembles d’enregistrements de la zone. La DNSKEY publiée permet aux validateurs de vérifier ces signatures.

Si les signatures et la clé publiée ne correspondent pas, le comportement correct d’un résolveur validant n’est pas de deviner l’intention de l’opérateur, mais de considérer les données comme bogus, c’est-à-dire non authentifiables.

Le point central de cet incident est donc une relation d’état, pas seulement une panne de serveur. DENIC exploitait une troisième génération de système de signature, entrée en service en avril 2026, combinant Knot DNS, des composants développés en interne et plusieurs modules matériels de sécurité répartis sur deux centres de données géographiquement et réseau-distincts. Le rapport final de DENIC attribue la cause à une erreur dans un agent interne de rotation: au lieu de générer une paire de clés et de la charger sur tous les HSM connectés, l’agent a créé une paire distincte pour chaque HSM.

Ces clés portaient pourtant les mêmes métadonnées et le même key tag, 33834, tout en contenant du matériau cryptographique différent.

Cette nuance est importante. DENIC a explicitement distingué le cas d’une collision classique de key tag. Il ne s’agissait pas non plus, selon le rapport final, d’un dysfonctionnement de Knot DNS, d’un dysfonctionnement des HSM ou d’une compromission. La défaillance publique se situe dans l’orchestration de la rotation et dans la manière dont le système a rendu cohérentes, ou plutôt n’a pas rendu cohérentes, les clés et les signatures produites par plusieurs HSM. Un même identifiant apparent ne suffisait pas: le contenu cryptographique effectif n’était pas le même partout.

La conséquence directe était que la zone publiée ne pouvait être validée que pour une partie des signatures générées. Une seule DNSKEY publique avait été inscrite dans la zone, et seul le HSM qui détenait la clé privée correspondante pouvait produire des signatures valides par rapport à cette DNSKEY. DENIC a expliqué qu’en pratique environ un tiers des signatures générées validaient. Cette phrase doit rester ce qu’elle est: une relation entre la sortie de signature et la clé publiée.

Elle ne signifie pas qu’un tiers des domaines .de étaient accessibles, qu’un tiers des utilisateurs étaient épargnés, qu’un tiers du trafic fonctionnait, ni qu’une requête individuelle avait une probabilité fixe de succès. Les effets réels dépendaient des enregistrements interrogés, du moment, des caches, de la validation effectuée par les résolveurs, de l’évolution du SOA et de la redistribution de la zone.

Cette dimension temporelle compte aussi. DENIC a indiqué que le SOA changeait et était resigné au fil des mises à jour de zone. La validité pouvait donc varier avec l’état de la zone et avec la provenance des signatures. Dans une infrastructure DNSSEC, une zone n’est pas seulement un fichier publié; c’est un ensemble d’enregistrements, de signatures, de clés et de preuves négatives dont les relations doivent rester cohérentes. Une signature valide sur une version et invalide sur une autre ne se traduit pas directement en disponibilité stable pour un domaine ou une application.

La mesure publique disponible ne permet pas de reconstruire une matrice complète par domaine, par réseau, par minute ou par résolveur.

Le mécanisme d’impact s’étendait au-delà des domaines qui utilisaient eux-mêmes DNSSEC. DENIC a expliqué que les réponses de délégation au niveau du TLD dépendent aussi des enregistrements NSEC3 signés, notamment lorsqu’il faut prouver qu’un enfant non signé ne dispose pas d’un DS. NSEC3 sert à l’authentification du déni d’existence ou de certaines absences dans DNSSEC. Si les signatures de ces preuves ne valident pas, un résolveur validant peut considérer la délégation comme non fiable.

Ainsi, même un domaine de second niveau qui n’avait pas activé DNSSEC pouvait être touché, parce que la preuve signée au niveau .de concernant l’absence de DS ou la délégation devenait problématique. Ce n’est pas une bizarrerie arbitraire: c’est le fonctionnement de la validation quand la chaîne publiée ne peut pas être authentifiée.

La différence entre résolveurs validants et non validants a donc structuré l’expérience utilisateur. Les résolveurs qui appliquaient DNSSEC ont échoué en mode fermé: ils ont refusé des données qu’ils ne pouvaient pas authentifier. Les résolveurs non validants ont pu continuer à renvoyer des réponses. Il serait pourtant erroné d’en conclure que la bonne stratégie de résilience consiste à désactiver DNSSEC. DNSSEC existe pour empêcher qu’une réponse non authentifiée soit traitée comme fiable. Quand le registre publie un état signé incohérent, le validateur révèle le problème au lieu de le masquer.

La responsabilité se déplace alors vers les contrôles qui auraient dû empêcher la publication ou accélérer le retour à une zone correcte.

Cloudflare a ajouté une couche d’observation et de mitigation côté récursif. Son compte rendu indique que le résolveur 1.1.1.1 a utilisé des données périmées, lorsque cela était possible, afin d’amortir une partie de l’impact, puis a temporairement appliqué une Negative Trust Anchor pour .de après avoir confirmé le problème de signature côté autoritaire. Une NTA est une exception locale et temporaire par laquelle un résolveur traite une zone cassée comme non signée pour restaurer la résolution. Dans l’esprit opérationnel de ce mécanisme, elle doit être bornée, justifiée, surveillée et retirée lorsque la validation normale redevient possible.

Elle ne répare pas la zone; elle transfère une décision de sécurité limitée vers l’opérateur récursif.

Serve-stale répond à une logique différente mais complémentaire. Lorsqu’un résolveur dispose encore de données en cache, il peut, dans certaines conditions, servir temporairement une réponse expirée afin d’éviter une rupture brutale de disponibilité. Là encore, ce n’est pas une garantie universelle. Les caches ne contiennent pas toutes les réponses, toutes les durées de vie ne sont pas identiques et l’état des utilisateurs varie selon leur réseau, leur résolveur et le moment de la requête.

Dans cet incident, les mécanismes côté récursif ont pu réduire l’impact pour certains chemins, mais ils ne changent pas la cause: l’autorité .de distribuait un état DNSSEC qui ne validait pas de manière cohérente.

La séparation des couches est essentielle. DENIC possède la zone .de, ses signatures et les systèmes qui les génèrent et les publient. Les opérateurs de résolveurs récursifs contrôlent leurs politiques de validation, de cache, de serve-stale et, exceptionnellement, de NTA. Les utilisateurs et les domaines dépendaient de cette superposition. Une panne DNSSEC de TLD ne se mesure donc pas seulement par le nombre de serveurs autoritaires actifs.

Elle se mesure par la cohérence du matériau publié, par la capacité des validateurs à le vérifier, par le comportement des caches et par la rapidité avec laquelle un état connu comme bon peut être remis en circulation.

Le rapport final de DENIC fait aussi apparaître une frontière de tests. L’environnement de test comportait un seul HSM dans un seul lieu. Le défaut qui a déclenché l’incident nécessitait plusieurs HSM connectés. Il ne s’est donc pas exécuté dans cette topologie de test. Les scénarios existants ne couvraient pas ce cas, et DENIC indique que les tests antérieurs, l’audit externe et l’exploitation parallèle à froid n’ont pas révélé ce comportement propre à l’environnement réel. C’est un point de contrôle majeur.

Le problème n’est pas que DENIC manquait de redondance matérielle; le problème est que cette redondance introduisait une condition d’état distribuée que le laboratoire ne reproduisait pas.

Cette distinction change la manière d’évaluer la préparation. Un test de code peut être propre tout en manquant la condition qui naît de la multiplicité des HSM. Un audit peut vérifier des procédures sans exercer la combinaison exacte de génération, chargement, métadonnées, key tag, signatures, SOA et publication. Une marche parallèle à froid peut montrer que des composants fonctionnent séparément sans prouver que l’autorité de basculement, la validation complète et le blocage de publication couvrent le même graphe d’état que l’environnement réel. La parité recherchée n’est pas seulement une parité de version logicielle.

Elle doit inclure la topologie, la concurrence, les relations de clé, les chemins de signature et la sémantique de panne.

Les HSM multiples sont souvent présentés comme une mesure de sécurité et de continuité, et ils le sont dans de nombreux modèles de risque. Ils protègent les clés, réduisent certaines dépendances physiques et peuvent soutenir des architectures réparties. Mais dans cet incident, la multiplication des HSM a exposé une autre exigence: tous les éléments qui participent à une même identité cryptographique publiée doivent partager un état réellement compatible.

Si trois HSM signent sous une identité apparente commune mais que seule une clé privée correspond à la DNSKEY publiée, l’infrastructure dispose de capacité matérielle, mais pas d’un état signé commun. La capacité se transforme alors en réplication d’incohérence.

Le même raisonnement vaut pour l’anycast et les sites multiples. L’anycast améliore la disponibilité en rapprochant les serveurs des réseaux, en répartissant la charge et en absorbant certaines défaillances de site ou de chemin. DENIC décrit son service de noms comme distribué sur plusieurs sites et réseaux. Cette architecture est précieuse contre des incidents physiques, des congestions locales ou certaines coupures de transit. Elle ne rend pas une zone cryptographiquement invalide soudainement valide.

Si tous les nœuds servent, ou finissent par servir, un état signé défectueux, l’étendue géographique accélère la diffusion de l’erreur autant qu’elle soutient normalement la continuité.

L’incident montre donc une règle simple: la résilience de transport ne remplace pas l’intégrité de la donnée signée. Dans le DNS, surtout au niveau d’un TLD, l’identité n’est pas seulement l’adresse d’un serveur; elle est la relation vérifiable entre délégations, clés, signatures et preuves. Le registre ne peut pas déclarer que la zone est correcte si les validateurs, en exécutant les règles publiques de DNSSEC, prouvent le contraire. L’autorité opérationnelle est contrainte par le code en fonctionnement et par les résultats vérifiables. C’est précisément ce qui rend l’épisode pertinent pour la responsabilité d’infrastructure.

Le rapport final contient un autre fait déterminant: DENIC affirme que trois systèmes de test et de validation continus ont détecté les signatures manquantes ou non validables comme prévu, mais que leurs notifications n’ont pas été traitées correctement. Cette phrase déplace l’analyse de la détection vers l’intervention. Il ne suffit pas qu’un outil voie le problème. Un contrôle utile doit avoir une conséquence opérationnelle: bloquer la publication, forcer une décision humaine explicite, déclencher une escalade, enclencher un retour arrière ou empêcher la poursuite d’une distribution tant qu’un artefact validé n’existe pas.

Une alerte ignorée, mal routée ou insuffisamment possédée est un enregistrement d’échec, pas une protection effective.

La question de responsabilité devient alors: quel résultat de validation avait autorité sur la publication de la zone? Si un outil détecte des RRSIG non validables, qui reçoit le signal? Quel délai d’accusé de réception est obligatoire? Que se passe-t-il si l’accusé de réception n’arrive pas? Qui peut déclarer que la zone candidate est publiable? Quelle preuve indépendante établit que les DNSKEY, les RRSIG, les enregistrements NSEC3 et les délégations se vérifient de bout en bout? Le rapport public ne donne pas tous ces éléments. Il montre toutefois que la présence de validateurs n’a pas suffi à transformer la détection en arrêt préventif.

La rotation de clés DNSSEC n’est pas une opération exceptionnelle dans la vie d’un registre. Les documents opérationnels sur les rollovers existent précisément parce que ces changements doivent être planifiés, mesurés et réversibles. Une ZSK rollover réussie n’est pas seulement la génération d’une nouvelle clé. Elle suppose la coordination entre publication DNSKEY, signatures, caches, délais de propagation, validateurs et possibilité de retour à un état connu. Dans un TLD comme .de, l’échelle rend l’opération plus sensible, mais la logique reste la même: chaque étape doit pouvoir être vérifiée avant que la dépendance publique ne soit engagée.

Dans le cas DENIC, l’agent interne de rotation a créé une incohérence que le modèle de test n’avait pas exposée. Cette incohérence a ensuite été autorisée à produire des signatures et à entrer dans une distribution visible par les résolveurs. La responsabilité technique ne se limite donc pas au bug. Les bugs existent dans tout système complexe. L’analyse porte sur les barrières successives: tests équivalents à l’environnement réel, validation de la zone candidate, autorisation de publication, traitement des alertes, décision de basculement, retour à un état connu comme bon et communication externe.

Plus l’infrastructure est critique, plus la défense doit reposer sur plusieurs barrières vérifiables, pas sur l’absence présumée d’erreur dans un composant.

La restauration rapportée suit elle aussi une logique de contrôle. DENIC a indiqué que la distribution d’une zone correcte a commencé à 00 h 08 et que l’état antérieur de fonctionnement a été restauré à 01 h 15. Ces repères sont importants, mais ils ne répondent pas à toutes les questions. Combien de temps a-t-il fallu pour identifier précisément le matériau fautif? Quel artefact a été choisi comme connu bon? Comment a-t-il été validé indépendamment? Quelle partie de la distribution l’a reçu en premier? Quels tests externes ont confirmé la récupération depuis plusieurs réseaux?

La publication d’une chronologie ne remplace pas la preuve détaillée du mécanisme de retour arrière, mais elle permet de cadrer les demandes de preuve ultérieures.

L’épisode ne doit pas être confondu avec d’autres incidents de TLD, y compris la panne .de de mai 2010 ou l’événement .ru de 2024. Ces comparaisons peuvent être utiles dans une étude distincte sur les registres, mais elles dilueraient ici la causalité. Le cas de mai 2026 est assez précis: une rotation DNSSEC, un agent interne, plusieurs HSM, un key tag commun avec matériau distinct, une DNSKEY publiée, des signatures partiellement validables, des effets NSEC3 sur des délégations, des résolveurs validants qui échouent fermé et une récupération pendant la nuit. C’est cette chaîne qui doit rester au centre.

Les sources publiques imposent aussi des limites de mesure. On ne dispose pas du code fautif, du graphe exact de déploiement, de la planification de sélection des HSM, des sorties brutes des trois validateurs, de la configuration complète des alertes, ni d’une carte par réseau ou par domaine de la disponibilité effective. Les descriptions médiatiques de grande échelle donnent une idée de la dépendance potentielle, mais elles ne sont pas une mesure minute par minute de l’indisponibilité. Il serait donc imprudent de transformer l’incident en chiffre global d’utilisateurs, de domaines ou de pertes économiques sans données supplémentaires.

La rigueur consiste à maintenir ces inconnues visibles.

Cette prudence ne réduit pas la gravité. Un TLD est une couche de dépendance commune. Quand la validation de délégation devient incertaine au niveau du registre, la panne peut atteindre des services qui n’ont pas eux-mêmes changé de configuration. La responsabilité d’un registre porte précisément sur cette continuité de la couche commune: unicité des délégations, exactitude des données, métadonnées de sécurité cohérentes et possibilité de transfert ou de résolution selon les règles publiées. Dans DNSSEC, ces obligations se matérialisent sous forme de clés, signatures, DS, NSEC3, SOA, délais et comportements de résolveurs.

La mesure de responsabilité ne doit pas chercher un individu à blâmer dans le vide. Elle doit demander quels contrôles étaient censés empêcher le passage d’un état invalide. Pour la prévention, la question est la parité des tests: le système d’essai reproduit-il le nombre de HSM, la distribution des sites, les chemins de signature, les métadonnées partagées et les scénarios de split state? Pour la détection, la question est la couverture: les validateurs vérifient-ils l’ensemble de la chaîne, y compris DNSKEY, RRSIG, NSEC3 et délégations, avant distribution?

Pour le blocage, la question est l’autorité: un échec critique peut-il arrêter automatiquement ou obliger une décision formelle avant publication?

Pour le retour arrière, la question est l’artefact connu bon. Un registre doit savoir quel état antérieur peut être réintroduit, comment il est signé, comment il est validé et comment sa distribution est confirmée. Pour la mitigation côté récursif, la question est la coordination sans délégation de responsabilité: les serve-stale et NTA peuvent réduire la douleur, mais ils ne doivent pas devenir le plan primaire d’un registre. Pour la communication, la question est la séparation des temps: génération, validation, distribution, observation par résolveurs, mitigation et récupération doivent être distinguées.

Pour l’assurance indépendante, la question est la preuve: les engagements annoncés doivent produire des résultats vérifiables.

DENIC a annoncé plusieurs mesures après l’incident: renforcement de l’examen du code, amélioration de l’alerte, basculement accéléré vers une zone valide, validation partielle avant déploiement, suspension de nouvelles rotations ZSK jusqu’à des travaux supplémentaires, extension de l’environnement de test, ainsi qu’analyses externes de sécurité et de processus. Ces mesures sont pertinentes, mais elles doivent être traitées comme des engagements nécessitant des preuves ultérieures. Elles ne démontrent pas, par leur seule annonce, que chaque contrôle est complet, exercé, mesuré et efficace.

La différence entre intention et preuve est particulièrement importante dans une infrastructure qui a déjà montré que la détection sans intervention ne suffisait pas.

Un registre peut sortir renforcé d’un incident si ses corrections deviennent observables. Une extension de laboratoire est utile si elle reproduit réellement la multiplicité des HSM et les chemins de signature. Une amélioration d’alerte est utile si elle impose des propriétaires, des délais, des escalades et des essais réguliers. Un basculement accéléré est utile si son temps est mesuré depuis une détection externe et interne, et si l’artefact basculé a été validé par une chaîne indépendante.

Une validation partielle avant déploiement est utile si la partie validée correspond aux modes de panne qui ont causé l’incident; sinon elle peut devenir une nouvelle case cochée qui laisse persister le risque principal.

Les standards DNSSEC et les documents opérationnels donnent un langage pour cette analyse. Les RFC 4033, 4034 et 4035 définissent les concepts et comportements de validation. La RFC 5155 encadre NSEC3. Les documents sur les rollovers et sur les conséquences de changements de clés rappellent que la planification et la propagation ne sont pas accessoires. La RFC 7646 permet de situer les Negative Trust Anchors comme exceptions temporaires côté résolveur. La RFC 8767 décrit serve-stale comme un amortisseur de disponibilité sous conditions.

La RFC 8901, sur les modèles multi-signers, fournit une comparaison utile pour réfléchir aux systèmes où plusieurs entités ou composants participent à la signature, même si l’incident DENIC n’est pas simplement un déploiement multi-signer classique. La RFC 8976, sur ZONEMD, peut être comprise comme un mécanisme ultérieur d’intégrité de zone, mais elle ne doit pas être présentée comme une solution qui aurait, à elle seule, empêché cet incident.

L’enseignement le plus robuste est donc moins spectaculaire qu’un récit de panne globale, mais plus utile. DENIC n’a pas décrit une attaque. DENIC n’a pas imputé la panne à Knot DNS ou aux HSM. DENIC n’a pas décrit une collision classique de key tag. Le rapport pointe une erreur d’orchestration interne dans une architecture distribuée, puis des contrôles de validation et d’alerte qui n’ont pas empêché l’état invalide d’atteindre les résolveurs.

C’est une forme de risque propre aux infrastructures modernes: les systèmes sont redondants, les composants sont spécialisés, les validations existent, mais la relation entre tous ces éléments peut encore manquer d’une autorité opérationnelle claire.

Dans un registre, l’état signé est l’unité réelle de continuité. Les serveurs, les sites et les HSM ne sont que les moyens de le protéger, le générer et le distribuer. Lorsqu’ils servent un état valide, la redondance augmente la résilience. Lorsqu’ils participent à un état incohérent, elle élargit la portée du défaut. Pour les responsables d’infrastructure réseau, la question après mai 2026 n’est pas seulement: combien de copies du service existent? Elle est: quelle preuve indépendante montre que toutes les copies servent la même vérité cryptographique?