DNSSEC-storing bij .de op 5 mei 2026: wat ging er mis en wat kunnen .nl-eigenaren leren?
Op 5 mei 2026 was een groot deel van het Duitse internet plotseling onbereikbaar. Geen DDoS-aanval, geen offline datacenter, maar één gebroken cryptografische handtekening op het hoogste niveau van de DNS-hiërarchie. DENIC, de registry van het .de-domein, publiceerde tijdens een routinematige sleutelrotatie ongeldige DNSSEC-handtekeningen. Het gevolg: miljoenen .de-domeinen waren ruim tweeënhalf uur lang onbereikbaar voor iedereen die een validerende DNS-resolver gebruikte.
Wat is er precies gebeurd, hoe reageerden grote resolver-operators, en vooral: wat kun je hier als Nederlandse domeineigenaar van leren?
Wat ging er mis bij .de op 5 mei 2026?
Rond 19:30 UTC begon DENIC ongeldige DNSSEC-handtekeningen te publiceren in de .de-zone. Validerende resolvers zijn volgens de DNSSEC-specificatie verplicht zulke records te weigeren en SERVFAIL terug te geven aan clients. Volgens DENIC zelf ontstond de fout tijdens een geplande key rollover, waarbij niet-valideerbare handtekeningen werden aangemaakt en gedistribueerd. Toekomstige rollovers zijn voorlopig opgeschort tot de exacte oorzaak is vastgesteld.
Cloudflare publiceerde een uitgebreide reconstructie van het incident. Hun publieke resolver 1.1.1.1 paste pas rond 22:17 UTC een mitigatie toe.
De impact in cijfers
- Aanvang storing: 5 mei 2026, circa 19:30 UTC
- Mitigatie 1.1.1.1: circa 22:17 UTC (ruim 2 uur en 45 minuten impact)
- Getroffen domeinen: in principe alle .de-domeinen achter een validerende resolver
- .de behoort tot de meest bevraagde top-level domains ter wereld
Hoe kan één misser bij de registry zo veel kapot maken?
DNSSEC werkt met een keten van vertrouwen (chain of trust). De rootzone vertrouwt .de via een Delegation Signer (DS) record. De .de-zone vertrouwt vervolgens elke individuele zone, zoals voorbeeld.de, via een eigen DS-record. Als ergens in die keten een schakel breekt, valt alles eronder uit, ongeacht of de individuele domeinen zelf foutloos geconfigureerd zijn.
DNSSEC gebruikt twee soorten sleutels:
- Zone Signing Key (ZSK): tekent de records in de zone.
- Key Signing Key (KSK): tekent de ZSK en is verankerd bij de ouderzone via het DS-record.
Een ZSK rouleren is relatief eenvoudig: nieuwe sleutel genereren, records hertekenen, wachten tot caches verlopen. Een KSK rouleren is complexer omdat ook het DS-record bij de ouderzone moet worden bijgewerkt. Precies dat soort proces ging bij DENIC mis.
Belangrijk om te onthouden: DNSSEC gaat over integriteit, niet over privacy. Records blijven zichtbaar, maar hun authenticiteit kan worden bewezen.
Hoe reageerden de grote resolver-operators?
Serve stale (RFC 8767)
Veel resolvers, waaronder Cloudflare's 1.1.1.1, implementeren "serving stale" volgens RFC 8767. Wanneer upstream-resolutie faalt, mag een resolver tijdelijk verlopen cache-records blijven serveren. Hierdoor bleven veel .de-domeinen waarvan records al in cache stonden gewoon bereikbaar, ondanks de gebroken validatie. De impact van zo'n grote storing wordt op die manier flink gedempt.
Negative Trust Anchors (RFC 7646)
Voor verse queries, en voor records waarvan de TTL inmiddels was verlopen, was er een drastischer middel nodig: een Negative Trust Anchor (NTA). RFC 7646 definieert dit als een expliciete uitzondering: de resolver behandelt een specifieke zone tijdelijk alsof DNSSEC niet actief is.
Een NTA is geen perfecte oplossing. Cryptografische integriteit wordt tijdelijk uitgeschakeld, dus theoretisch zijn cache-poisoning- en MITM-aanvallen mogelijk. Maar bij een publiek bekende en breed gerapporteerde TLD-storing weegt beschikbaarheid op tegen dit kortdurende risico. Zoals Cloudflare het in hun incident room verwoordde: er is geen gebruiker die liever een SERVFAIL krijgt dan een ongevalideerd antwoord.
Wat betekent dit voor .nl-domeineigenaren?
Deze storing trof .de, maar .nl is niet immuun. SIDN, de registry van .nl, voert ook reguliere sleutelrotaties uit. De les is niet "schakel DNSSEC uit", want dat zou een achteruitgang in veiligheid betekenen. De les is dat je weet wat er gebeurt als upstream iets fout gaat én dat je je eigen DNSSEC-keten goed in de gaten houdt.
Concreet:
- Monitor je DNSSEC-keten doorlopend. Een DS-record dat niet meer matcht met je actieve DNSKEY veroorzaakt exact dezelfde SERVFAIL-storing als bij .de, alleen dan op je eigen domein.
- Stel realistische TTL-waarden in. Hele korte TTLs maken snel switchen mogelijk, maar geven serve stale minder buffer bij upstream-incidenten. Een TTL van enkele uren is voor de meeste records een redelijke balans.
- Test je sleutelrotaties. Of je dit zelf beheert of via een DNS-provider: vraag hoe rollovers worden geautomatiseerd, welke validatie er vooraf plaatsvindt, en wat er gebeurt bij een mislukking.
- Heb een communicatieplan klaar. Als je domein onbereikbaar is door een TLD-storing kun je technisch weinig doen. Klanten en collega's tijdig informeren via een tweede kanaal (status-pagina, sociale media, e-mail vanaf een ander domein) maakt het verschil.
Hoe helpt DNSWatcher hierbij?
DNSWatcher monitort continu de DNSSEC-keten van je domein. Matcht je DS-record nog met je actieve DNSKEY? Verlopen er handtekeningen binnenkort? Klopt de NSEC/NSEC3-keten? Een afwijking is vaak de eerste indicatie dat een rotatie scheefloopt, soms uren tot dagen voordat eindgebruikers SERVFAIL beginnen te zien.
Was deze .de-storing met monitoring te voorkomen geweest? Nee, want het was een upstream-fout bij DENIC waar individuele domeineigenaren geen controle over hebben. Maar je had wél binnen minuten geweten dat validatie faalde en proactief kunnen communiceren in plaats van afhankelijk te zijn van boze klanten die je bellen.
Veelgestelde vragen
Was mijn .nl-domein ook getroffen?
Nee. De storing zat puur in de .de-zone bij DENIC. Andere TLDs, waaronder .nl, .com, .org en .eu, functioneerden gewoon normaal.
Moet ik DNSSEC nu uitschakelen?
Nee. DNSSEC blijft een essentiële verdediging tegen DNS cache poisoning en man-in-the-middle-aanvallen. Deze storing toont aan dat misconfiguratie pijnlijk is, niet dat de technologie zelf faalt. Vergelijk het met onderzeese internetkabels: dat ze soms beschadigd raken, betekent niet dat we van glasvezel af moeten.
Hoe weet ik of mijn DNSSEC werkt?
Een snelle test is dig +dnssec voorbeeld.nl @1.1.1.1 op de commandline. Externe validators zoals DNSViz en de Verisign DNSSEC Debugger geven een visuele weergave van de hele keten. Voor doorlopende bewaking is geautomatiseerde monitoring sterk aan te raden.
Wat is een Negative Trust Anchor precies?
Een NTA, gedefinieerd in RFC 7646, is een tijdelijke configuratie-uitzondering waarmee een DNS-resolver de DNSSEC-validatie voor één specifieke zone overslaat. Het wordt ingezet bij publiek bekende, breed verspreide misconfiguraties zoals deze .de-storing, om beschikbaarheid te herstellen terwijl de oorzaak wordt opgelost.
Hoe lang duurde de storing precies?
DENIC begon rond 19:30 UTC met het publiceren van ongeldige handtekeningen. Cloudflare's 1.1.1.1 paste rond 22:17 UTC een NTA-equivalent toe, waarna .de-resolutie via die resolver weer normaal werd. De totale hersteltijd verschilde per resolver-operator en per domein, afhankelijk van TTL-instellingen en wanneer de cache van een specifiek record verliep.
Wat is het verschil tussen ZSK en KSK?
De Zone Signing Key (ZSK) tekent de individuele records in een zone. De Key Signing Key (KSK) tekent alleen de DNSKEY-record-set, inclusief de ZSK. De KSK is aanmerkelijk zwaarder (langere sleutel) en wordt minder vaak gerouleerd. Rotatie van de KSK vereist coördinatie met de ouderzone via een nieuw DS-record en is daardoor foutgevoeliger.
Conclusie
De .de-storing van 5 mei 2026 is een herinnering dat zelfs correct functionerend DNSSEC kwetsbaar is voor één enkele misser hoog in de keten. Voor Nederlandse domeineigenaren is de boodschap niet "vermijd DNSSEC", maar "monitor je keten actief en weet wat je doet als upstream iets fout gaat".
Snelle detectie maakt het verschil tussen een SERVFAIL die je via je dashboard ontdekt en een incident waar je via boze klanten achter komt. En in 2026 mag dat eigenlijk niet meer het verschil zijn tussen "we wisten het al" en "we kwamen er net achter".
Bronnen en verder lezen:
