Volledige .de-domein was vier uur offline vanwege Dnssec-probleem bij beheerder

Het volledige .de-domein is in de nacht van dinsdag op woensdag bijna vier uur onbereikbaar geweest. Geen enkele .de-website was te bezoeken omdat .de-beheerder Denic een probleem had met Dnssec.

De problemen ontstonden rond 21.50 uur op dinsdagavond. Toen meldden gebruikers voor het eerst op grote schaal dat Duitse domeinen niet meer te bereiken waren. Beheerder Denic eG schreef een korte blogpost met de melding van een probleem, maar geeft daar nog geen gedetailleerde oorzaak van. Denic is de beheerder van het .de-domein, vergelijkbaar met het Nederlandse SIDN of het Belgische DNS Belgium.

De storing lag volgens Denic bij 'een verstoring in zijn DNS-diensten voor .de-domeinen. "Als gevolg zijn alle .de-domeinen die met Dnssec zijn getekend, getroffen in hun bereikbaarheid."

Vanwege die Dnssec-problemen zette onder andere Cloudflare DNS-validatie uit op .de-domeinen, zodat de alternatieve 1.1.1.1-resolver wel werkte met Duitse websites.

De storing was rond 2.00 uur 's nachts weer verholpen, al hadden sommige websites daarna alsnog last van de slechte bereikbaarheid. Wat er precies misging, is nog steeds niet bekend; Denic zegt nog aan een analyse te werken. De storing is opvallend groot; dat een volledig topleveldomein niet bereikbaar is, komt zelden voor. Denic had al aangekondigd onderhoud te gaan plegen in de liveomgeving.

Update, 07.59 uur – In het artikel stond aanvankelijk dat de storing van zondag op maandag plaatsvond, maar dat was van dinsdag op woensdag.

Reacties (77)

[Goldwing1973]

.DE is toch een TLD? En niet een “domein”?

[MischaBoender]

"de" is een domein, "germany.de" is een domein, "berlin.germany.de" is een domein... Technisch is het mogelijk om een A record aan een top-level domein te hangen (zie bijvoorbeeld het .ws domein), maar dit wordt streng afgeraden en waarschijnlijk zal dit ook niet universeel werken op endpoints. Voor gTLD domeinen (zoals .berlin) mag dit contractueel niet (ICANN policy).

[Martink]

Geloof dat Google dat een tijdje heeft gedaan met hun .google TLD. Maar dit gaf problemen. Weet niet meer precies wat

[Habbie]

Dat hebben ze als het goed is niet gedaan, want in new gTLDs is dat verboden door ICANN

[storeman]

Waar staat de D voor in TLD?

[Goldwing1973]

Sorry, eerste koffie nog niet op…

[Heroic_Nonsense]

In dit geval?

"Tschüss, Leider Defekt"

[NMe]

Waarom noemt het artikel de T en L niet? Daar valt toch echt een stuk informatie weg door de keuze van de redactie om geen Engelse termen te willen gebruiken.

[Plymp]

Top-level domain. Hoogste niveau, maar nog steeds een domein.

[bergsegek]

niet het hoogste niveau maar wel het 2de niveau.

het begint bij "." waar alle TLD's registreren.

[beerse]

De punt in een domein-naam is voor het onderscheid in niveau. In theorie kan je het mail adres koffie@de krijgen. Al denk ik dat DouweEgberts het niet voor elkaar kan krijgen om het mx-record in de "de" tld te krijgen.

Wel kan je dat heel goed zelf in je eigen netwerk opzetten. Tegenwoordig is de tld "local" (en mogelijk ook "lokaal") thuis vrij te gebruiken. Stel dat in op je eigen dns-server en speel er mee rond. Als de software netjes wil meewerken kan je alle internet-zaken zo zelf thuis uitproberen.

En er is mogelijk een uitdaging in dat je de default-dns-suffix voor moet zijn. In principe is de domeinnaam namelijk een toevoeging aan de machine-naam om aan te geven in welk domein ze geregistreerd is. En omdat de domeinnaam er voornamelijk is om de machine naam aan te geven. Dus de meeste software verwacht wel degelijk een punt in de dns-naam. Maar dat is vooral voor het onderscheid tussen de hostname en de domainname.

[Sandro!]

.local is voor mDNS (RFC 6762), dat kun je prima buiten mDNS om gebruiken maar je kunt dan wel problemen op je netwerk krijgen.

[bergsegek]

ik bedoel de root " ." niet de domein.nl punt alle top level domeinen moeten ergens beginnen om het internet te navigeren.
Wikipedia: Root name server

vanuit deze root kunnen alle tld adressen worden opgezocht en hieronder komen de domein namen die hieraan vast zitten. een soort boom van vertrouwen.

Dit is mij althans geleerd op mijn Systeembeheer schooling mbo/hbo

[beerse]

Vanuit mijn kennis/ervaring is de punt die je achter de tld kan en mag zetten de indicatie dat hier geen dns-suffix-search-list gebruikt hoeft/kan/mag worden, dat de naam volledig is. Toegegeven, dat is een andere manier om naar die finale punt te kijken.

Met jouw manier van kijken is er een vergelijking met het unix (linux) filesysteem: het begint allemaal bij de root (de wortel) en daar bouwen we op.

[ouweklimgeit]

en waar staat TLD voor?

[WaterFire]

Top Level Domain.
Wikipedia: List of Internet top-level domains

[Lagonas]

Je bedoelt de TLD van Top Level Domain?

[Reactie gewijzigd door Lagonas op 6 mei 2026 08:00]

[mOrPhie]

Technisch gezien is het een domein, maar technisch gezien schrijf je het als "de." en niet ".de", dus imho moet Tweakers ook gewoon tld schrijven zoals de rest van de wereld. Semantisch wordt het nu ook lastig te zoeken op al het nieuws over tld's.

[bergsegek]

Klopt .de is een top level domain beheerd door de vertrouwde instanties welke blijkbaar Denic heet.
Bij deze organisatie registreer jij je domein zoals wij hem kennen onzin.de en richt je waar de DNS server te vinden is voor dit domein.

Op deze DNS server kun je aankloten wat je wil met je domein naam maar vertrouw je er wel op dat het TLD zijn zaakjes op orde heeft.

een dns verzoek gaar namelijk eerst kijken bij "." waar het TLD ".de" te vinden is en welke verwijst waar "onzin" te vinden is. en vraag aan het DNS van onzin waar bijvoorbeeld het A record of MX etc etc etc te vinden is.

"een volledig domein naam zou dan onzin.de. zijn"

het is dus een keten van vertrouwen

[MischaBoender]

Vanwege die Dnssec-problemen zette onder andere Cloudflare DNS-validatie uit op .de-domeinen, zodat de alternatieve 1.1.1.1-resolver wel werkte met Duitse websites.

Ik weet eerlijk gezegd niet of dit zo handig is, ivm de veiligheid.

[kuurtjes]

Dit volgt de officiele richtlijnen van RFC 7646:

DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

[MischaBoender]

Ik kan jouw reactie, als reactie op mijn eigen reactie, niet modereren, maar wilde toch even zeggen dat dit een goede toevoeging is. 👌🏻

Deze RFC laat inderdaad ruimte om DNSSEC validatie tijdelijk uit te zetten als het duidelijk is dat de problemen worden veroorzaakt door misconfiguratie en niet door een "malicious actor".

[djmuggs]

Nee, is niet handig.

Maar als je jezelf serieus neemt als organisatie of bedrijf, dan gebruik je je eigen resolvers en niet die van cloudflare.


Voor huis, tuin en keuken gebruiker was er mogelijk een probleem met .de domeinen Kwa veiligheid.

[pe0mot]

Eigen DNS zal ook niet werken als toplevel een fout heeft. Elke eigen resolver zal vanuit de bovenkant van de boom (root) weer bij Denic uitkomen.

[MischaBoender]

Als er DNSSEC problemen zijn dan is het de bedoeling dat resolving niet werkt. Een eigen resolver zou niet moeten resolven als DNSSEC niet gevalideerd kan worden. Cloudflare heeft op hun resolver dus de DNSSEC validatie uit gezet, waardoor je mogelijk "verkeerde" IP adressen terug kreeg.

[YGDRASSIL]

Of bijn alle duitse websites volledig onbereikbaar voor de normale mens of een tijdelijke manier die een safety check overslaat. Die keus is snel gemaakt. Als ze maar niet vergeten het nu weer aan te zetten....

[baseoa]

Dus als je ooit een exploit weet waarvoor het nodig is dat dnssec even uit staat... de keus is schijnbaar snel gemaakt als je het eruit weet te leggen door bijvoorbeeld grote dnssec records op te vragen in een DDoS!

[YGDRASSIL]

Het komt zelden voor dat een TLD er volledig uitligt voor DNSSEC. Dus dat lukt blijkbaar niet zo makkelijk. Maar inderdaad, als je de hele TLD eruit kan mikken en dan een hack klaar hebt die het alleen kan zonder dnssec dan heb je meer kans van slagen.

[FrostyPeet]

Toch beetje eng dat een heel TLD offline kan gaan voor nieuwe resolves. Terwijl "internet" toch werd verkocht als "nuke proof" eind vorige eeuw. Gelukkig was er een alternatief.

[YGDRASSIL]

Het TLD was niet offline. Neem aan dat je op IP nummer gewoon alle sites kon bezoeken? De dns lookups werkten niet.

[AW_Bos]

Dat werkt ook niet altijd als IP-adressen niet zijn gebind aan domeinnamen. Kijk eens naar shared hostings. Een snelle oplossing (of kan dat nog sneller) is om je host-file aan te passen, en de hostname mee te geven in de header.

[Reactie gewijzigd door AW_Bos op 6 mei 2026 10:03]

[baseoa]

Dat is een ander protocol. DNS kan eruit liggen en je kunt nog steeds in de Host header aangeven welke site je wilt hebben van het IP-adres waar je tegen babbelt

[Heroic_Nonsense]

Het internet wel, het web niet.

Op IP-adres waren de sites immers nog gewoon bereikbaar

[Alex3]

Ook andere diensten gebruiken dns, b.v. e-mail.

[MPAnnihilator]

zelden nog aanvaarden webservers een IP nog als geldige host header...

[baseoa]

Toch moet je verbinden met een IP-adres. Dat je dan aan de server moet zeggen welke site je graag had staat volledig los van, en werkt zonder tussenkomst van, DNS

[MPAnnihilator]

Je kan wel verbinden met een IP adres, als de achterliggende webserver niet ingesteld is om te antwoorden op het IP adres, dan ga je als client niets te zien krijgen. Het is de admin van de webserver, of de application firewall ervoor, die bepalen op welke host headers een webserver uiteindelijk gaat reageren. 't Is niet omdat je op een IP uitkomt ( ofwel door dns vertaling, of doordat je zelf het IP kent ) dat je per definitie iets te zien krijgt... zo werkt het niet. edit : typo's

[Reactie gewijzigd door MPAnnihilator op 6 mei 2026 17:39]

[baseoa]

Wederom, toch verbindt je onder water met een IP-adres (dat je van DNS krijgt, en ook zelf lokaal kan opslaan voor als DNS eruit ligt) en komt al het andere daar bovenop. Probeer het zonodig uit. Met TLS SNI en Host headers morrelen is deel van mijn werk als pentester en hobby als sysadmin, ik weet hoe een WAF en webserver werkt

[Reactie gewijzigd door baseoa op 9 mei 2026 13:10]

[MPAnnihilator]

Tweakers is een mooi voorbeeld. Nslookup geeft ( bij mij ) deze IPv4 IP's 2.16.6.12 & 2.16.6.33 in theorie moet jij dezelfde vertaling krijgen. Surf nu maar eens naar https://2.16.6.12 of https://2.16.6.33 Dat doet helemaal niets, omdat de webserver of alles wat ervoor staat, een simpel IP niet in zijn lijst van acceptabele host headers heeft staan. De GET moet tweakers.net zijn bijvoorbeeld, dan lukt het wel. Komt er nog bij dat we hier connecteren naar https://... dan moet het certificaat van de website ook nog eens additioneel de IP's als SAN naam hebben staan om het te laten werken in moderne browsers.... kortom, direct surfen naar het IP is iets van de jaren 80, nu werkt dat niet meer, tenzij je een proof of concept gebouwd hebt om aan te tonen hoe DNS werkt ofzo...

[baseoa]

De manier die jij beschrijft stuurt niet de juiste server name indication en ook niet de juiste host-header. Zie bovenstaande reacties nog eens. Het staat echt los van DNS (mijn server antwoordt ook op domeinen die in DNS nooit naar mijn server verwezen hebben), maar je moet niet domweg de browser naar het IP laten surfen zonder verdere informatie

[MPAnnihilator]

Het ging hier over het DNS systeem dat op TLD niveau een onderbreking had. Mijn reactie op Heroic_Nonsense zijn post was er om aan te duiden dat simpelweg surfen naar het IP niet ging werken. Hij meldde "Op IP-adres waren de sites immers nog gewoon bereikbaar". Dan lees ik hier tussen de regels dat hij bedoelt ipv surfen naar https://tweakers.net, gewoon surfen naar https://2.16.6.12.

Ik denk dat wij gewoon allebij hetzelfde willen zeggen hoor.

[GertMenkel]

Nuke proof was de belofte in vergelijking met eerdere systemen, waarbij specifieke adressen over specifieke links werden gestuurd die handmatig werden geconfigureerd.

Je kunt redundante servers opzetten zoveel je wilt, maar als je redundante servers verkeerd worden geconfigureerd en verkeerde antwoorden sturen, blijf je met de gebakken peren zitten.

[zx9r_mario]

Dns kwam pas later. Daarvoor wisselde ze hostfiles uit.

[dasiro]

don't blame the computer for human stupidity

[GenomDalar1983]

De rest van het internet was toch niet plat, toch?

[locke960]

Het internet is "nuke proof". Het internet gaat over verbindingen en automatisch routeren van datapakketjes over andere verbindingen als verbindingen uitvallen.

DNS is geen internet. Een Webserver is geen internet. AWS is geen internet. Dat zijn allemaal dingen die bovenop het internet draaien. Als je die dingen ontwerpt met eigen ingebouwde single-point-of-failures dan helpt het niet dat het onderliggende netwerk robuust is.

Het wegennet is ook "nuke proof". Als den Haag genuked wordt kun je nog van Rotterdam naar Amsterdam via Utrecht. Maar dan moet je auto het wel doen natuurlijk.

[HKLM_]

Volledig is ook wat overdreven.. volgens APNIC maakt ongeveer 80% van de .de domeinen gebruik van DNSSEC, blijft er nog een 20% van de .de sites over die niet getroffen zijn.

[LeonM]

Niet helemaal. De .de zone (het TLD) is zelf ook signed, en die signature was niet geldig. Dus alle .de domeinen waren getroffen, ook als het domain zelf geen DNSSEC zone signing gebruikt.

[Jay-v]

Volgens mij werkt het zo niet. DNSSEC is chain based, als ik geen DS records heb voor mijnsite.de wordt de hele validatie geskipped, ook een NS query.

Staat overigens ook zo in het bron artikel

As a result, all DNSSEC-signed .de domains are currently affected in their reachability.

[Reactie gewijzigd door Jay-v op 6 mei 2026 08:32]

[mdavids]

Volgens mij werkt het zo niet. DNSSEC is chain based, als ik geen DS records heb voor mijnsite.de wordt de hele validatie geskipped,

Oh ja?

En hoe bepaalt de resolver dan dat er geen DS voor mijnsite.de is in .de ?

[Reactie gewijzigd door mdavids op 6 mei 2026 13:05]

[Jay-v]

Fair point, dat doet de resolver door te bepalen of er een NXDOMAIN response terug komt (van .de). Maar ook dat antwoord moet ook geverifieerd worden natuurlijk.

[alm]

Het zou logischer zijn dat de validatie wel gedaan wordt voor zones waarop het aan staat, dus als op de TLD DNSSEC aan staat (dus er is een DS-record in de parent) en de DNS Resolver doet aan validatie dan lijkt het me logisch dat het antwoord wat je krijgt uit de TLD gechecked wordt. Dat betekent niet dat de hele chain dan vervolgens op DNSSEC gevalideerd moet worden, dat hangt er weer vanaf of er een DS-record is voor de opgevraagde zone in de parent. Als er een onderbreking is, dus stel je hebt een subdomein (child) waarvoor een DS-record in de parent (het domein dus) staat en parent zelf heeft geen eigen DS-record in zijn parent (bijvoorbeeld de TLD), dan is de keten onderbroken heb je dus ook geen DNSSEC-validatie op het subdomein.

Het hangt er daarnaast helemaal vanaf of de resolver aan DNSSEC-validatie doet of niet, als die dat niet doet heb je dus ook geen last gehad van de verstoring bij het opvragen van .de domeinen.

Ik zal eens kijken wat mijn eigen resolvers doen om te zien of wat ik logisch vind ook daadwerkelijk gebeurt.

edit:
Validatie vindt dus ook plaats op de TLD en parentdomeinen i.g.v. een subdomein.

[Reactie gewijzigd door alm op 6 mei 2026 22:36]

[Habbie]

De tekst in het bron-artikel klopt niet (of, specifieker, is incompleet). Ook unsigned .de domains hadden last.

[GertMenkel]

Het probleem voor veel resolvers zal zijn geweest dat het .de-domein zelf niet werkte.

Dat is natuurlijk alleen een probleem bij resolvers die DNSSEC valideren. Door het matige protocolontwerp achter DNSSEC is het namelijk de resolver die verantwoordelijk is voor de validatie, niet de client, en de resolver zet een bitje aan dat zegt "is veilig hoor". Je kunt je client vaak instellen om DNSSEC zelf te valideren, maar in de meeste gevallen is dat opt-in.

Voor de Duitsers is dat een probleem, maar voor veel anderen juist weer niet: https://stats.labs.apnic.net/dnssec

[Reactie gewijzigd door GertMenkel op 6 mei 2026 10:24]

[Tozz]

Zeker wel, want als de DNSSEC validatie voor .DE stuk is dan stopt het resolven al.

Het antwoord op de vraag "Wie is de DNS server voor tweakers.de" wordt al niet geaccepteerd vanwege falende DNSSEC. Of tweakers.de dan zelf DNSSEC gebruikt of niet is dan niet relevant.

Het gaat eerder al mis.

[lenwar]

De ene 80% is de andere 80% niet. Goede kans dat die 80%, ongeveer 100% van de belangrijkste sites omvat (overheden, banken, techsites 😜, zoekmachines, webmail, streamingdiensten, enz, enz, enz.)

[beerse]

Tel daarbij dat heel veel dns verkeer wordt gebufferd, inclusief dat de security ook niet meteen is verlopen. Daarmee kan het zomaar zo zijn dat veel gebruikers er niet direct last van hebben.

[Bart ®]

https://isitdns.com/

[Wolfos]

Bijzonder dat een website met één woord op een zwarte achtergrond 3,8kb aan HTML en bijna 20kb aan Javascript binnenhaalt, waaronder Google Tag Manager want het moet uiteraard bijgehouden worden dat je hier geweest bent...

[Justientje]

Het is altijd dns

[segil]

nee, het is altijd de firewall

[Arthur Tromp]

Ik dacht dat het altijd de gebruiker was.

[segil]

dat sowieso

[arjankoole]

behalve als het BGP is.:-p (toch, facebook?)

[AzzKickah]

Het is altijd accu.

[Webgnome]

.de nial of service..

[gdhaaijer]

De problemen ontstonden rond 21.50 op zondagnacht.

Zondag of dinsdag?

[Reactie gewijzigd door gdhaaijer op 6 mei 2026 08:05]

[Ohmarinus]

Aha, ik vroeg me al af waarom DHL.de gisteren niet werkte. Ik dacht dat het probleem bij DHL lag. Toch wel weer interessant en waardevol om te lezen hoe het echt zat.

[rootpowered]

Dat verklaart een hoop. Gisteravond heb ik voor het eerst een bestelling gedaan op een Duitse webshop, maar later was die ineens offline. Ik was even bang dat mijn geld verdwenen was.

[baseoa]

Mijn vriendin was ook iets op een .de aan het bestellen toen ik het verse nieuws zag. Heb 'r aangeraden de bestelling af te ronden zolang de caches nog heet zijn xD. Gelukkig ging dat goed, ook incl. betalen waarvoor ik bang was dat het een nieuw domein zou moeten laden. Misschien liep dat via stripe punt com. We vroegen ons af of, als dit tot in de ochtend duurt, dingen als hun back-end nog wel werken of dat in het warenhuis alles chaos is. Tot dusver niks gehoord, en gezien het opgelost was voor drieën... ik had de popcorn an aangebroken maar er lijkt uiteindelijk niks aan het handje

[Reactie gewijzigd door baseoa op 6 mei 2026 13:08]