Quand l'infrastructure d'un registre lâche : l'incident .de et ses leçons

En mai dernier, l'internet allemand a connu un gros bug. Amazon.de inaccessible. Les services de Deutsche Telekom en panne. DHL, la SNCF allemande, Spiegel : tout bloqué. Pourtant, les serveurs d'hébergement tournaient nickel. Les domains étaient bien enregistrés. Les DNS pointaient correctement. Les dashboards montraient du vert partout. Mais des millions d'internautes voyaient des timeouts.

Le souci se cachait ailleurs.

La couche cachée qui a tout fait planter

Les pannes au niveau registry, c'est comme un sol qui s'effondre sous ta maison. Impossible de réparer avec un coup de peinture. DENIC, le registry du .de, venait de lancer sa troisième génération d'infra pour gérer la zone. Code neuf. Audits sécurité OK. Tests externes validés. Puis, le 5 mai, rotation des clés programmée. Et boum, catastrophe.

Point technique : le système devait créer une clé crypto unique, distribuée sur trois appareils sécurisés. Pratique standard pour DNSSEC, qui vérifie cryptographiquement les réponses DNS. Pour s'assurer que tu parles au vrai domain, pas à un piège d'attaquant.

Mais le code buggé a généré trois clés différentes. Une publiée. Les deux autres ont signé quand même, incompatibles. Résultat : deux tiers des signatures DNSSEC .de invalides mathématiquement. Les resolvers stricts – Google's 8.8.8.8, Cloudflare's 1.1.1.1, Quad9 – ont rejeté tout et servi des erreurs.

Le piège du monitoring

Frustrant : les outils de DENIC ont détecté le problème. Trois systèmes de validation ont alerté en minutes. Et ensuite ? Rien. Les alertes sont restées sans suite. Trois heures plus tard, résolution. Pas par DENIC en premier.

Un schéma classique. Du monitoring auto sans gestion d'incidents réactive, c'est du cinéma. Ça donne l'illusion de contrôle. Tout vert jusqu'au chaos. Des millions d'impacts, et un délai de trois heures dans la réponse.

Pourquoi l'impact variait (et pourquoi c'est grave)

L'asymétrie dérange : certains utilisateurs tout cassé, d'autres rien. Ça dépendait du resolver DNS.

Les resolvers modernes comme 1.1.1.1 ou 8.8.8.8 valident DNSSEC par défaut. Ils refusent les signatures foireuses. Les vieux resolvers ISP ? Beaucoup ignorent DNSSEC. Ils servent quand même. Résultat : le net de mamie marche, celui de ta startup plante. Juste à cause du resolver choisi.

Problème d'infra invisible : la sécu avance si l'écosystème suit. Sinon, elle amplifie les pannes au lieu de les bloquer.

La leçon sur la sécu DNS

Seulement 3,6 % des .de ont DNSSEC – environ 645 000 sur 17,9 millions. Faible adoption, donc impact limité aux gros sites bien gérés, avec DNSSEC et resolvers validateurs. Les majors touchées. Les petits OK.

Vérité dure : plus d'adoption DNSSEC (et il faut), plus ces incidents frappent fort et large. Pas de sécu sans douleur de transition.

Ce que ça change pour ta stratégie domain

Pour tes domains critiques, repense ton DNS :

Diversifie tes resolvers. Pas tout sur un seul public. Teste plusieurs. Surveille lequel tu utilises vraiment. Certaines apps basculent auto. Exploite ça.

Connais les procédures d'incidents du registry. Tous les ccTLD ne gèrent pas pareil. Pour un gros trafic en .de, sache qui fait quoi et comment ils alertent. DENIC a publié un rapport clair, mais le délai d'alerte a révélé une faille.

DNSSEC compte – mais vérifie l'implémentation. La panne .de vient de DNSSEC, d'une génération de clé ratée. Pas de boycott. Exige tests solides, validation continue, réponse rapide du registry.

Surveille les bonnes couches. Dashboard hosting vert ? Inutile si registry HS. Intègre du monitoring registry dans tes checks. Cloudflare donne des alertes précoces, avant les plaintes clients.

Le rôle de Cloudflare

Cloudflare a fixé en premier. Pas un hasard. Leur 1.1.1.1 touché direct. Avec nameservers globaux, ils isolent vite. Ils trackent DNS à grande échelle.

Choisir un bon DNS provider, c'est plus que "ça marche". Ils voient les pannes réseau-wide, triangulent ce que tu rates seul.

Les correctifs appliqués

DENIC a upgradé la rotation de clés. Amélioré l'escalade d'alertes. L'infra gen3 debuggée, pas démontée. Code défectueux patché. Monitoring upgradé pour déclencher vraiment les incidents.

Du basique : meilleurs tests, alertes efficaces, docs procedures. Pas glamour, mais ça évite la prochaine panne de trois heures.

La vraie leçon

L'infra registry est un angle mort pour la plupart. C'est invisible. Registrar gère. Registry gère. Toi, tes DNS et hosting. Chacun son bout.

Mais les bouts se touchent, et ça peut craquer. Visibilité multi-couches essentielle : santé registrar, perf resolvers, réponse registry. La panne .de montre : pas d'externalisation totale de ta sécu DNS. Comprends les couches sous ton app, même gérées par d'autres.

Leçon du 5 mai : les pires fails frappent où tu ne commandes pas. D'où l'importance de les piger.