Quand un seul bug a fait tomber 16 millions de domaines : Retour sur la panne DNS .de

Soyons honnêtes : personne ne pense au DNS tant que tout fonctionne. Le jour où ça plante ? C'est le chaos total.

Le 5 mai 2026, le registre allemand DENIC a appris cette leçon à ses dépens. Pendant environ trois heures, accéder aux domaines .de relevait du quitte ou double. Certains marchaient, la plupart non. Les résolveurs validant à travers le monde crachaient des erreurs "bogus" comme des confettis dans une fête qui a mal tourné.

La cause technique ? Une erreur unique dans un logiciel de rollover personnalisé. Mais le pourquoi de cette panne, c'est là que ça devient intéressant. Et c'est là que chaque développeur et engineer infrastructure devrait prêter attention.

Ce qui s'est passé

L'infrastructure de signature DNSSEC pour les domaines .de combine des logiciels standards (Knot resolver) et des développements internes maison, le tout fonctionnant via des HSMs. Imaginez les HSMs comme des coffres-forts cryptographiques surpuissants qui génèrent et stockent les clés privées protégeant la zone DNS.

Lors d'un rollover de clé routinier en mai 2026, l'agent de rollover personnalisé — le logiciel chargé de générer le matériel cryptographique et de le distribuer sur tous les HSMs — a malfunctionné. De façon subtile, mais catastrophique.

Voilà le problème : au lieu de générer une seule paire de clés et de la distribuer à tous les HSMs, le code défectueux en a généré trois séparées — une pour chaque HSM. Pire : les trois paires ont terminé avec des métadonnées identiques, notamment le même key tag (33834).

Résultat ? Quand la zone a été publiée, un seul des trois HSMs possédait la clé privée correspondant à l'enregistrement DNSKEY public. Résultat : environ un tiers des signatures DNSSEC pouvaient être validées. Le reste ? Invalides. Et en DNSSEC, une signature invalide ne veut pas dire "probablement ok" — ça veut dire "bogus".

Pourquoi les tests n'ont rien détecté

C'est ici que l'histoire devient précieuse pour quiconque écrit du code d'infrastructure.

Le bug de l'agent de rollover ne se manifeste que quand plusieurs HSMs sont connectés. Et voici le problème : l'environnement de test ne comprenait qu'un seul HSM, dans un seul emplacement.

Avec un seul HSM dans votre setup de test, générer "une paire de clés par HSM" et "une paire de clés pour tous les HSMs" produit des résultats identiques. Le code défaillant a passé tous les tests parce que l'environnement de test ne reflétait pas la réalité de production.

C'est un cas classique d'échec de parité d'environnement — un phénomène que chaque développeur connaît théoriquement mais qu'on croise encore et toujours en pratique. L'environnement de test était "suffisant"… jusqu'au jour où il ne l'a plus été.

Le paradoxe de la supervision

Voici la partie vraiment frustrante : les systèmes de monitoring de DENIC ont effectivement détecté le problème.

Trois outils de validation tournaient en continu, vérifiant les signatures manquantes ou non validables. Ces systèmes ont fait exactement ce qu'ils étaient censés faire — ils ont identifié les anomalies.

Mais les alertes générées n'ont pas été traitées correctement. Les notifications ont été envoyées, les humains ne les ont pas reçues à temps (ou n'ont pas agi), et la zone défectueuse a continué d'être publiée pendant trois heures critiques.

C'est un schéma qu'on retrouve encore et encore : la supervision qui détecte les problèmes n'a de valeur que celle du processus de réponse aux incidents qui traite ces détections. Vous pouvez avoir la meilleure stack d'observabilité au monde, mais si les alertes échouent silencieusement ou si les playbooks de réponse sont flous, vous volez quand même à l'aveugle.

Certains gros opérateurs de résolveurs ont compris ce qui se passait et ont temporairement désactivé la validation DNSSEC pour les domaines .de — en gros, ils ont dit à leurs résolveurs "fais confiance mais ne vérifie pas" pour les domaines allemands. Ça a atténué les dégâts pour leurs utilisateurs, mais ça montre à quel point nos hypothèses de validation peuvent être fragiles.

L'effet domino : pourquoi des domaines non validés ont aussi cassé

Voici une subtilité qui rend cet incident particulièrement instructif : les domaines qui ont cessé de fonctionner n'utilisaient pas nécessairement DNSSEC eux-mêmes.

La validation DNSSEC fonctionne récursivement. Quand un résolveur interroge un domaine .de, la réponse inclut des enregistrements NSEC3 qui prouvent que certains enregistrements n'existent pas dans la zone. Ces enregistrements NSEC3 doivent être signés — et si ces signatures sont invalides, toute la réponse est marquée comme suspecte.

Donc même si le domaine de votre startup allemande n'utilise pas DNSSEC du tout, la chaîne de délégation prouvant que votre domaine existe requiert toujours des signatures valides. Quand ces échecs de validation se sont propagés, des domaines n'ayant aucune configuration DNSSEC sont devenus intraçables.

DNSSEC n'est aussi fort que sa zone la plus faible. Les signatures de la zone .de qui échouent ont fait que tout le TLD semblait compromis aux résolveurs validants.

Ce que les équipes infrastructure doivent retenir

1. Tester dans des environnements similaires à la production

Ça semble évident. Ça l'est évident. Et pourtant, ça arrive. Si votre code se comporte différemment avec un HSM versus trois, votre environnement de test a besoin de trois HSMs. Oui, c'est plus cher. Oui, c'est plus complexe. C'est quand même nécessaire.

2. Les scénarios d'échec doivent être testés, pas seulement les chemins happy path

Le processus de code review a raté ça parce que les scénarios de test couvraient les happy paths. Qu'est-ce qui se passe quand le réseau partitionne ? Quand des HSMs sont ajoutés ou retirés ? Quand les clés se désynchronisent ? Les tests adversariaux contre vos propres hypothèses ne sont pas optionnels.

3. Du monitoring sans runbooks, c'est juste du bruit

Des alertes que personne ne sait comment traiter — ou qui se déclenchent à 3h du mat' sans chemin d'escalade clair — n'empêchent pas les pannes. Elles les documentent. Chaque alerte doit avoir un runbook associé. Chaque runbook doit être testé trimestriellement.

4. La redondance n'est pas juste pour le hardware

L'infrastructure de DENIC avait des HSMs distribués sur deux datacenters géographiquement séparés. Mais l'architecture logicielle partait du principe que tous les HSMs se comporteraient identiquement. Une vraie redondance, c'est concevoir pour l'échec de vos hypothèses, pas juste de vos composants.

5. Pensez au rayon d'impact

Quand vous concevez une infrastructure critique, posez-vous la question : qu'est-ce qui se passe quand ça casse, et jusqu'où les dégâts se propagent ? L'incident .de a affecté des domaines qui n'avaient rien à voir avec DNSSEC directement. C'est un rappel que dans les systèmes distribués, les dépendances circulent dans des directions inattendues.

La bonne nouvelle

DENIC a géré ça avec une transparence admirable. Le rapport final a détaillé exactement ce qui s'est passé, pourquoi les garde-fous existants ont échoué, et les mesures concrètes mises en place — incluant des processus de code review améliorés et des protocoles de réponse aux incidents renforcés.

L'écosystème DNSSEC apprend de ces incidents. Chaque panne majeure — chaque .de, chaque Dyn, chaque couac Cloudflare — nous enseigne quelque chose sur la construction d'infrastructures plus résilientes. La clé, c'est d'appliquer vraiment ces leçons.

En résumé : Le DNS est le héros méconnu d'Internet… jusqu'à ce qu'il ne le soit plus. La panne .de de mai 2026 est un rappel que même des opérations matures et bien financées, avec plusieurs couches de protection, peuvent être humiliées par un simple bug au bon endroit au mauvais moment.

Pour les développeurs et les équipes infrastructure, le message n'est pas la peur — c'est la vigilance. Testez ce que vous livrez. Supervisez ce que vous testez. Et ne supposez jamais que votre environnement de test reflète parfaitement la production.

Parce que quand le DNS casse, tout casse. Et la leçon coûte toujours plus cher quand on l'apprend tard dans la stack.