Wanneer de .de-registratie crasht: binnenkijken in de grootste outage en de lessen die we leerden
De .de-storing: Wat een registry-falen ons leerde over DNS-veiligheid
Vorig jaar mei viel het Duitse internet deels plat. Amazon.de was onbereikbaar. Diensten van Deutsche Telekom, DHL en de Bahn verdwenen. Zelfs Spiegel-online ging offline. Servers draaiden prima. Domeinen stonden correct geregistreerd. DNS-records wezen naar de juiste plekken. Toch zagen miljoenen gebruikers foutmeldingen.
Het probleem zat dieper.
De fout in de kern
DENIC, de registry voor .de-domeinen, had net een nieuwe infrastructuur uitgerold. Derde generatie, met verse code. Alles doorgelicht: security-checks en externe tests oké. Op 5 mei volgde een routine key rotation voor DNSSEC. En toen liep het spaak.
Kort technisch: het systeem moest één cryptografische sleutel maken en die over drie beveiligingsmodules verdelen. Standaard voor DNSSEC, dat DNS-antwoorden controleert op echtheid. In plaats daarvan maakte de code drie verschillende sleutels. Eén werd gepubliceerd. De andere twee bleven signeren, maar klopten niet. Gevolg: tweederde van de .de DNSSEC-signaturen was ongeldig. Strenge resolvers zoals Google's 8.8.8.8, Cloudflare's 1.1.1.1 en Quad9 gooiden alles weg.
Monitoring die faalde
DENIC's eigen tools zagen het meteen. Drie systemen gaven alarm binnen minuten. Maar er gebeurde niks. Drie uur later was het opgelost – niet door DENIC, maar door anderen.
Automatiek zonder snelle actie is loos. Het oogt veilig met groene dashboards. Tot het misgaat, en je zit met een response-tijd van drie uur en massa getroffen users.
Waarom de impact verschilde
Niet iedereen had last. Het hing af van je DNS-resolver. Moderne zoals 1.1.1.1 en 8.8.8.8 checken DNSSEC streng en blokkeren fouten. Oudere ISP-resolvers negeren het vaak. Grootmoeders internet werkte door, terwijl techbedrijven vastliepen.
Dat toont het probleem: goede security helpt alleen als iedereen meedoet. Anders vergroot het storingen in plaats van ze te stoppen.
Lessen voor DNSSEC
Slechts 3,6% van de 17,9 miljoen .de-domeinen gebruikt DNSSEC – zo'n 645.000. De klap raakte vooral grote, beveiligde sites met strenge resolvers. Kleintjes bleven online.
Toch: meer DNSSEC betekent zwaardere storingen bij fouten. Je betaalt een prijs voor betere beveiliging.
Tips voor je domein-setup
Voor cruciale domeinen: pas je DNS-strategie aan.
Verspreid je resolvers. Gebruik er meerdere en check wat je echt queryt. Bouw failover in apps.
Ken de registry-procedures. Niet elke ccTLD reageert hetzelfde. Duik in DENIC's rapport voor inzichten.
DNSSEC wel, maar goed getest. Dit incident kwam door een key-fout. Eis testing en snelle fixes van je registry.
Check op registry-niveau. Een groene hosting-dashboard zegt niks over registry-problemen. Voeg registry-monitoring toe, zoals via Cloudflare.
Cloudflare's snelle fix
Cloudflare merkte het als eerste en loste het op. Hun globale netwerk zag de anomalie meteen. Goede DNS-providers spotten issues op schaal – dat scheelt.
Wat DENIC verbeterde
Nieuwe key-procedure. Betere alert-escalatie. Code gefixt, monitoring aangescherpt. Geen revolutie, maar solide basics: meer tests, snellere response, betere docs.
De kernboodschap
Registries zijn onzichtbaar voor domeinbeheerders. Registrar en registry regelen het. Jij doet je DNS en hosting. Tot de randen falen.
De .de-storing herinnert: uitbesteden is prima, maar begrijp de lagen eronder. Visibility in registrar, resolver en registry redt je. Critical failures zitten vaak buiten je controle – leer ze kennen.