Panique DNSSEC sur .de : ce qui a foiré et les leçons à tirer
Quand DNSSEC plante : les leçons de la panne .de
Vous avez déjà mis à jour une infra critique en pleine nuit ? Tout semble parfait en test, et boum, ça casse. C'est ce qui est arrivé au registre .de le 5 mai 2026.
Pendant trois heures, des milliers de sites .de ont été inaccessibles. Pas à cause d'un bug basique. Non, le système de sécurité DNSSEC les a littéralement sabotés.
Une tempête parfaite : tech + raté humain
Le registre .de bossait depuis des mois sur un nouveau système de signature DNSSEC de troisième génération. Tests poussés. Audits externes. Impeccable sur le papier.
Puis le drame : le système a créé trois paires de clés crypto au lieu d'une. Et n'en a publié qu'une. Résultat ? Les validateurs DNS ne trouvaient pas la bonne clé pour vérifier les signatures.
Côté technique, DNSSEC repose sur des "key tags", des empreintes des clés publiques. Là, les trois clés ont eu le même tag (33834). Deux tiers des resolvers ont rejeté les signatures. Car la clé privée de signature ne matchait pas la publique annoncée.
Pire : à chaque changement de zone, le SOA record se resigne. Certains updates passaient, d'autres non. Un chaos total pour les resolvers.
Les alertes ont bien fonctionné... mais alors ?
Le registre utilise trois outils de validation indépendants. Ils ont tous détecté les signatures foireuses et envoyé des alertes.
Personne n'a réagi.
Les notifs ont été loggées, noyées dans le flot des logs de prod. Pas un échec tech. Un échec de process. Ça peut arriver à n'importe qui gère de l'infra critique.
Leçon clé : le monitoring sans procédure de réponse, c'est du vent. Détection auto + escalade humaine claire = obligatoire.
L'effet domino : même les domaines sans DNSSEC touchés
Ce qui rend la panne vicieuse : DNSSEC ne protège pas que les domaines signés. Via NSEC3, il prouve aussi l'absence de signatures pour les unsigned.
Signatures invalides sur NSEC3 = resolvers rejettent toute la délégation des domaines de second niveau. Même ceux sans DNSSEC. Votre example.de unsigned ? Mort, car la pointe vers votre nameserver est "bogus".
Un piège subtil que peu d'opérateurs DNS anticipent.
Le sauvetage humain
Point positif : certains gros resolvers ont désactivé temporairement DNSSEC pour .de. Sites accessibles malgré les signatures cassées. Le registre les a remerciés publiquement.
L'internet qui fait son job : sous pression, les pros assouplissent les règles pour restaurer le service. Ça montre l'importance d'opérateurs DNS chevronnés.
Les leçons à retenir
Pour les devs et DevOps, voilà ce qu'on en tire :
Les tests ont des trous. Code audité, tests complets... et pourtant, la génération de clés multiples a passé inaperçue en pré-prod.
Alertes sans action = inutile. Trois systèmes parfaits, zéro réaction. Besoin d'escalade définie et d'attention humaine immédiate.
Connaissez vos dépendances. Impact sur unsigned domains prouve les liens cachés en DNS security. Un changement TLD = effet boule de neige.
Parallèle froid insuffisant. Le nouveau système tournait à côté du prod avant switch. Pas assez pour choper les diffs.
Documentez vos réponses aux incidents. Les resolvers pros savaient quoi faire. Et vous ?
Et après ?
Le registre .de creuse plus loin. On attend des tests DNSSEC renforcés, des process d'alerte améliorés, et peut-être des tweaks sur la gestion des zones TLD.
Pour nous sur NameOcean ou en auto-hébergement DNS :
- Choisissez des providers avec monitoring DNS solide et réponse rapide.
- Maîtrisez les implications DNSSEC avant activation.
- Réseautez avec des DNS ops expérimentés.
- Liez monitoring direct aux on-call, pas en silo.
Bonne nouvelle : après trois heures, .de était de retour. L'infra a tenu. Et on a appris sur les failles de nos bases internet.
Ça vaut le coup.
Vous avez vécu une panne DNS ? Quelles leçons en avez-vous tirées ? Racontez—ça renforce nos systèmes à tous.