Un domaine national a cessé de résoudre pendant plus d'une heure
Le domaine .al de l'Albanie s'est cassé ce mois-ci. Pendant plus d'une heure, les adresses de tout le pays ont cessé de résoudre : portails de l'État, médias et plateformes privées sans distinction. Les citoyens n'atteignaient plus les services publics, et les entreprises opérant sous des domaines albanais ont tout simplement disparu d'internet. L'AKEP, l'autorité nationale des communications électroniques et postales, a indiqué que le problème venait de systèmes situés à l'étranger qui gèrent une partie de l'infrastructure de .al. La cause était un renouvellement de clé DNSSEC raté, cet entretien cryptographique de routine censé rester invisible.
Pourquoi c'est important. DNSSEC existe pour prouver qu'une réponse DNS est authentique. Lorsque les signatures ne se valident pas, un résolveur correctement configuré doit refuser la réponse entièrement et renvoyer une erreur. C'est la norme qui fonctionne exactement comme elle a été conçue. Le mode de défaillance d'un contrôle de sécurité qui fait correctement son travail, c'est un pays qui passe hors ligne.
La solution a été d'éteindre la sécurité
Personne au registre ne pouvait réparer les signatures assez vite, alors le réseau a contourné le problème de la seule façon qu'il connaisse. Cloudflare a désactivé temporairement la validation DNSSEC pour .AL sur son résolveur 1.1.1.1, et d'autres opérateurs en ont fait autant. Le mécanisme s'appelle une ancre de confiance négative et ordonne au résolveur de traiter une zone signée comme si elle ne l'était pas. Il existe précisément pour ces incidents. La résolution est revenue. La validation, non.
Cloudflare avait posé la logique sans détour lors d'un épisode identique en mai : aucun utilisateur en train de résoudre l'un de ces noms ne préférerait une erreur à une réponse non validée. C'est très probablement exact, et c'est tout le problème. Le contrôle ne tombe pas en mode sûr et il ne tombe pas bruyamment. Il tombe en mode ouvert, par convention du secteur, au moment précis où un attaquant souhaiterait le plus le voir éteint.
Dix semaines plus tôt, la même chose est arrivée à .de
Le 5 mai 2026, vers 19h30 UTC, DENIC a publié des signatures DNSSEC défectueuses pour la zone .de. Les résolveurs qui valident étaient tenus de les rejeter et de renvoyer des erreurs, et l'un des domaines de premier niveau les plus vastes d'internet a commencé à s'effondrer. Les échecs ont grimpé pendant trois heures à mesure que les enregistrements en cache expiraient. DENIC a nommé la cause elle-même : un renouvellement de clé programmé et de routine, au cours duquel des signatures non validables ont été générées et diffusées. Les opérateurs de résolveurs ont déployé des ancres de confiance négatives en moins d'une heure, et 1.1.1.1 avait sa parade en place à 22h17 UTC.
Deux registres nationaux, à dix semaines d'intervalle, tous deux mis à terre par une maintenance planifiée et non par un attaquant. Ce n'est pas une histoire sur l'Albanie, et ce n'était pas une histoire sur l'Allemagne. C'est la même défaillance qui arrive deux fois, ce qui en fait un schéma et non un accident. Elle arrivera une troisième fois.
Le résolveur vous dit désormais quand il a cessé de vérifier
La vraie nouveauté est sortie de cet incident. À côté du contournement, Cloudflare a introduit l'Extended DNS Error 33, un code renvoyé dans la réponse elle-même qui signale que la validation DNSSEC a été contournée. Jusqu'ici, un résolveur qui avait discrètement abandonné la validation d'une zone était identique à un résolveur qui vérifiait encore. Vous obteniez une réponse, la réponse fonctionnait, et rien nulle part ne vous disait que la garantie cryptographique derrière elle était suspendue, peut-être pendant des heures et peut-être pour un domaine de premier niveau entier.
Ce qui change. Ce silence était l'exposition réelle. Celui qui inscrit DNSSEC dans un registre des risques, un questionnaire de sécurité ou un jeu de contrôles NIS2 affirmait jusqu'ici une chose qu'il ne pouvait pas observer. L'EDE 33 transforme un état invisible en état journalisé. C'est un petit ajout dans un paquet de réponse et c'est le premier signal honnête dans ce mode de défaillance.
Que faire d'une clé que vous ne détenez pas
Le plus inconfortable est le peu qui dépend de vous. Votre zone peut être signée impeccablement et votre domaine disparaître quand même, parce que la rupture s'est produite un étage plus haut, chez le registre qui exploite le suffixe de votre pays. NIS2 considère déjà les fournisseurs de services DNS et les registres de domaines de premier niveau comme des entités de haute criticité, ce qui revient à reconnaître que cette couche est systémique. Cela ne vous donne pas de levier. Ce que vous pouvez faire, c'est cesser de tenir cette couche pour inerte : surveillez si votre propre domaine résout depuis plusieurs résolveurs publics et pas seulement depuis le réseau du bureau, et notez ce que ces résolveurs répondent.
En résumé. Journalisez l'EDE 33 et déclenchez une alerte dessus. Si votre résolveur se met à signaler qu'il a contourné la validation pour votre domaine de premier niveau, vous êtes dans une fenêtre où les réponses DNS de votre domaine ne sont pas vérifiées, et il vaut mieux le savoir pendant que cela se produit plutôt que de le lire après coup. Deux pays ont déjà traversé cette fenêtre sans pouvoir la voir. Le troisième aura au moins une lumière allumée.
À lire ensuite: Votre dépendance au cloud est désormais un risque régulé. La plupart des entreprises ne voient même pas la leur. | Une faille Cisco de 18 ans, délai de 3 jours
