Een nationaal domein loste ruim een uur lang niet meer op

Het Albanese domein .al brak deze maand. Ruim een uur lang losten adressen in het hele land niet meer op: overheidsportalen, media en particuliere platforms evengoed. Burgers bereikten publieke diensten niet, en bedrijven die onder Albanese domeinen handelen verdwenen simpelweg van het internet. AKEP, de nationale toezichthouder voor elektronische communicatie en post, liet weten dat het probleem lag bij systemen in het buitenland die een deel van de .al-infrastructuur beheren. De oorzaak was een mislukte DNSSEC-sleutelwissel, dat routineuze cryptografische onderhoud dat onzichtbaar hoort te blijven.

Waarom dit telt. DNSSEC bestaat om te bewijzen dat een DNS-antwoord echt is. Als de handtekeningen niet valideren, moet een correct ingerichte resolver het antwoord volledig weigeren en een fout teruggeven. Dat is de standaard die precies werkt zoals hij ontworpen is. De faalwijze van een beveiligingsmaatregel die zijn werk goed doet, is een land dat offline gaat.

De oplossing was de beveiliging uitzetten

Niemand bij de registry kon de handtekeningen snel genoeg herstellen, dus ging het internet om het probleem heen op de enige manier die het kent. Cloudflare schakelde de DNSSEC-validatie voor .AL tijdelijk uit op zijn resolver 1.1.1.1, en andere resolveroperators deden hetzelfde. Het mechanisme heet een negatief vertrouwensanker en draagt een resolver op een ondertekende zone te behandelen alsof zij niet ondertekend is. Het bestaat juist voor dit soort incidenten. De resolutie kwam terug. De validatie niet.

Cloudflare had de logica bij een identiek voorval in mei onomwonden opgeschreven: geen enkele gebruiker die op dit moment zo'n naam opvraagt zou een foutmelding verkiezen boven een ongevalideerd antwoord. Dat klopt vrijwel zeker, en daarin zit het hele probleem. De maatregel faalt niet gesloten en hij faalt niet luid. Hij faalt open, bij afspraak in de sector, precies op het moment waarop een aanvaller hem het liefst uit zou hebben.

Tien weken eerder overkwam .de hetzelfde

Op 5 mei 2026, rond 19:30 UTC, publiceerde DENIC kapotte DNSSEC-handtekeningen voor de .de-zone. Resolvers die valideren moesten die weigeren en fouten teruggeven, en een van de grootste topleveldomeinen van het internet begon om te vallen. De storingen liepen drie uur lang op terwijl gecachete records verliepen. DENIC noemde de oorzaak zelf: een routineuze, geplande sleutelwissel waarbij handtekeningen werden aangemaakt en verspreid die niet te valideren waren. Resolveroperators zetten binnen het uur negatieve vertrouwensankers, en 1.1.1.1 had zijn maatregel om 22:17 UTC staan.

Twee nationale registries, tien weken uit elkaar, allebei onderuitgehaald door gepland onderhoud en niet door een aanvaller. Dit is geen verhaal over Albanië, en het was geen verhaal over Duitsland. Het is dezelfde storing die twee keer aankomt, en dat maakt er een patroon van in plaats van een ongeluk. Er komt een derde keer.

Nu vertelt de resolver u wanneer hij stopte met controleren

Het werkelijk nieuwe kwam uit dit incident. Naast de omweg introduceerde Cloudflare Extended DNS Error 33, een code die in het antwoord zelf meldt dat de DNSSEC-validatie is overgeslagen. Tot nu toe zag een resolver die de validatie voor een zone stilletjes had laten vallen er precies zo uit als een die nog controleerde. U kreeg een antwoord, het antwoord werkte, en nergens stond dat de cryptografische garantie erachter was opgeschort, mogelijk urenlang en mogelijk voor een heel topleveldomein.

Wat er verandert. Die stilte was de echte blootstelling. Wie DNSSEC opvoert in een risicoregister, een beveiligingsvragenlijst of een NIS2-maatregelenset, beweerde iets wat hij niet kon waarnemen. EDE 33 maakt van een onzichtbare toestand een gelogde. Het is een kleine toevoeging aan een antwoordpakket en het eerste eerlijke signaal in deze faalwijze.

Wat te doen met een sleutel die u niet in handen hebt

Het ongemakkelijke is hoe weinig hiervan aan u ligt. Uw zone kan onberispelijk ondertekend zijn en uw domein verdwijnt toch, omdat de breuk een niveau hoger plaatsvond, bij de registry die het achtervoegsel van uw land beheert. NIS2 behandelt DNS-dienstverleners en registers van topleveldomeinen al als entiteiten van hoge kritikaliteit, wat een erkenning is dat deze laag systemisch werkt. Een hefboom geeft het u niet. Wat u wel kunt doen, is die laag niet langer als roerloos beschouwen: bewaak of uw eigen domein oplost vanaf meerdere publieke resolvers en niet alleen vanaf het kantoornetwerk, en leg vast wat die resolvers terugmelden.

De kern. Log EDE 33 en alarmeer erop. Als uw resolver begint te melden dat hij de validatie voor uw topleveldomein heeft overgeslagen, zit u in een venster waarin de DNS-antwoorden voor uw domein niet geverifieerd zijn, en dat hoort u te weten terwijl het gebeurt in plaats van het achteraf te lezen. Twee landen zijn nu door dat venster gegaan zonder het te kunnen zien. Het derde heeft in elk geval een lampje.