DNSSEC voor domeineigenaren: wat het beschermt en hoe je het aanzet

DNSSEC voegt cryptografische handtekeningen toe aan de DNS-records van je domein, zodat een validerende resolver een vervalst antwoord weigert in plaats van de bezoeker naar de server van iemand anders te sturen. Inschakelen vraagt twee handelingen op twee plekken: je DNS-provider ondertekent de zone en je registrar publiceert een DS-record in de bovenliggende zone (.com, .net, een landendomein). Passen de twee helften niet meer bij elkaar (een oude DS na een sleutelwissel of een verhuizing naar een andere DNS-provider, verlopen handtekeningen), dan geven validerende resolvers SERVFAIL en verdwijnt de site voor ongeveer 40% van de internetgebruikers, terwijl alle anderen hem gewoon blijven zien.

Waartegen DNSSEC beschermt en waartegen niet

DNSSEC beantwoordt één vraag: komt dit DNS-antwoord echt ongewijzigd van de eigenaar van de zone? Alles wat het wel en niet kan, volgt daaruit.

De vertrouwensketen: twee helften op twee plekken

Je DNS-provider beheert de sleutels van de zone, meestal twee: de KSK (key signing key) ondertekent de sleutelset, de ZSK (zone signing key) al het andere. De publieke delen staan als DNSKEY-records in de zone, en elke recordset draagt een RRSIG-handtekening. Een ondertekende zone bewijst op zichzelf niets, want iedereen kan een zone met een eigen sleutel ondertekenen. Daarom stuurt je registrar het register een DS-record, een hash van je KSK. De zone .com is ondertekend met de sleutel van het register, en daarvoor staat de root weer garant. Een resolver heeft alleen de rootsleutel nodig en loopt de keten schakel voor schakel af.

Een gevalideerde keten op onze testopstelling (uitvoer van drill -S):

www.good.lab. (A)
|---good.lab. (DNSKEY keytag: 64049 alg: 13 flags: 256)
    |---good.lab. (DNSKEY keytag: 63839 alg: 13 flags: 257)
    |---good.lab. (DS keytag: 63839 digest type: 2)
        |---lab. (DNSKEY keytag: 42416 alg: 13 flags: 256)
            |---lab. (DNSKEY keytag: 50413 alg: 13 flags: 257)
            |---lab. (DS keytag: 50413 digest type: 2)
                |---. (DNSKEY keytag: 16174 alg: 13 flags: 256)
                    |---. (DNSKEY keytag: 65449 alg: 13 flags: 257)
;; Chase successful

Voor een site-eigenaar is het belangrijkste signaal de vlag ad (authenticated data) in het antwoord van een validerende resolver:

$ dig @127.0.0.1 www.good.lab A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22876
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
www.good.lab.   300 IN A     192.0.2.10
www.good.lab.   300 IN RRSIG A 13 3 300 20261124104054 20261110141320 64049 good.lab. 3q/P...

Op het echte internet gebruik je dig +dnssec example.com @1.1.1.1 of delv example.com: delv valideert de keten zelf en toont ; fully validated. DNSViz tekent elke schakel van de keten.

DNSSEC inschakelen voor je domein

1. Zoek uit wie je DNS-provider en wie je registrar is. dig NS example.com +short toont de servers die voor de zone antwoorden. Zitten DNS en registratie bij dezelfde partij, dan is DNSSEC vaak één schakelaar en wordt de DS automatisch doorgegeven.
2. Zet ondertekening aan bij je DNS-provider. De server maakt sleutels aan en ondertekent de zone. Hij moet ook zelf opnieuw ondertekenen: op onze testopstelling zette BIND met dnssec-policy handtekeningen die ongeveer 14 dagen geldig waren en vernieuwde ze zelf. Handmatig ondertekenen zonder automatisering eindigt in verlopen handtekeningen.
3. Haal het DS-record op. Het heeft vier velden: key tag, algoritme, digesttype en digest. Voorbeeld uit de test: good.lab. 3600 IN DS 63839 13 2 0E1736F2... (algoritme 13 = ECDSA P-256, type 2 = SHA-256). Sommige registrars vragen in plaats daarvan de DNSKEY met vlag 257.
4. Voeg de DS toe bij je registrar. De registrar geeft hem door aan het register en hij verschijnt in de zone .com (of van een ander topleveldomein). Sommige registers kunnen de DS automatisch overnemen uit CDS/CDNSKEY-records (RFC 8078), maar reken daar niet bij voorbaat op.
5. Controleer. dig DS example.com +short hoort je DS te tonen, en dig example.com +dnssec @1.1.1.1 de vlag ad. Krijg je in plaats daarvan SERVFAIL, verwijder de DS dan direct bij de registrar en zoek het verschil.

Is je domein bij RichHost geregistreerd, vraag dan aan de support of DNSSEC ervoor kan worden ingeschakeld en hoe je het DS-record aanlevert: de support werkt van 10:00 tot 20:00 uur (Kyiv-tijd) en antwoordt binnen ongeveer 30 minuten. Voor de hosting zelf zie je de hostingpakketten van RichHost.

Hoe een gebroken keten een site laat verdwijnen: drie storingen in de test

In alle drie de gevallen draaide de gezaghebbende server en gaf hij het juiste IP-adres terug. Alleen de validatie faalde, dus de hostinglogs tonen niets bijzonders, terwijl bezoekers achter een validerende resolver SERVFAIL krijgen. Voor hen is de site gewoon onvindbaar, net als bij andere DNS-fouten in de browser. Unbound legt de oorzaak uit met een EDE-code (Extended DNS Error), de nuttigste aanwijzing bij het zoeken naar de fout.

1. Nieuwe sleutel, oude DS

We vervingen de KSK van roll.lab en ondertekenden de zone opnieuw, maar lieten de oude DS in het ‘register’ staan. Dat gebeurt als sleutels met de hand worden gewisseld of als een zone met nieuwe sleutels naar andere servers verhuist.

15:14:53 KSK 8235 replaced by 51389, parent DS still 8235
15:14:54 resolver 2 (cold): SERVFAIL  EDE 6 (DNSSEC Bogus): no keys have a DS with algorithm ECDSAP256SHA256
15:14:54 resolver 1 (warm): NOERROR ad 192.0.2.10
15:18:59 resolver 1 (warm): NOERROR ad, TTL 12
15:19:29 resolver 1 (warm): SERVFAIL  EDE 6 (DNSSEC Bogus)
15:23:00 correct DS (51389) published in the "registry"
15:27:30 both resolvers: SERVFAIL (old DS cached with TTL 3600)
15:27:48 resolver 2 after unbound-control flush_zone roll.lab: NOERROR ad
16:15:09 resolver 1, no intervention: NOERROR ad

Het verraderlijke: een resolver die de sleutels van de zone al kende, bleef nog 4,5 minuut normaal antwoorden (TTL 300). De eigenaar controleert de site, ziet dat hij werkt, terwijl nieuwe bezoekers al een foutmelding krijgen. Ook het herstel gaat niet meteen: we publiceerden de juiste DS om 15:23, maar de resolver hield de oude DS vast voor de volle TTL (3600 seconden) en gaf pas om 16:15 weer normale antwoorden, 52 minuten later. In totaal was de site via deze resolver 56 minuten onbereikbaar. In .com is de TTL van een DS 24 uur, dus op het echte internet kan deze fout een hele dag kosten. Google Public DNS zegt caching meestal tot 6 uur te beperken, en zowel Google als Cloudflare laten je een domein handmatig uit hun cache verwijderen.

2. Verlopen handtekeningen

We ondertekenden expold.lab met handtekeningen die al 2 uur eerder waren verlopen. De resolver is daar duidelijk over:

$ dig @127.0.0.1 www.expold.lab A +dnssec
;; status: SERVFAIL
; EDE: 7 (Signature Expired): (validation failure <www.expold.lab. A IN>: signature expired from 127.0.22.10 for key expold.lab. while building chain of trust)

Interessant is wat er gebeurt op het moment van verlopen. We ondertekenden explive.lab met handtekeningen die 25 minuten geldig waren (tot 15:28:07) en vernieuwden ze nooit. Unbound weigerde ze niet meteen: het tolereert een klokafwijking van 10% van de looptijd van de handtekening, maar minstens een uur (val-sig-skew-min, standaard 3600 seconden). Daardoor accepteerde de resolver om 16:26:19 nog een vers antwoord met de vlag ad, en verscheen SERVFAIL met EDE 7 pas om 16:32:19, 64 minuten na het verlopen. Andere resolvers hanteren hun eigen marge, dus verlopen handtekeningen halen een site in golven onderuit, niet voor iedereen tegelijk. De enige bescherming is automatisch opnieuw ondertekenen plus het bewaken van de vervaldatum van de RRSIG (zichtbaar in dig +dnssec, bijvoorbeeld 20261124104054).

3. Verhuizing naar een DNS-provider zonder DNSSEC, oude DS blijft staan

Het meest voorkomende geval bij site-eigenaren: het domein verhuist naar een nieuwe DNS-provider (nieuwe NS-records), maar de DS van de vorige provider blijft bij de registrar staan. De nieuwe provider serveert de zone onondertekend, terwijl de bovenliggende zone nog steeds zegt dat hij ondertekend moet zijn. We vergeleken twee volgordes op identieke zones (TTL van delegatie en DS: 300 seconden):

moved.lab (DS left in place)
15:15:05 NS switched to the new host without DNSSEC, DS untouched
15:19:12 SERVFAIL  EDE 9 (DNSKEY Missing)
15:22:02 DS removed in the "registry"
15:23:53 SERVFAIL  (resolver still holds the cached DS)
15:24:13 NOERROR 198.51.100.20

moved2.lab (DS removed first)
15:15:05 DS removed, old NS kept
15:19:12 NOERROR 192.0.2.10 without ad
15:20:31 NS switched to the new host
15:24:13 NOERROR 198.51.100.20, no SERVFAIL at any point

De verkeerde volgorde gaf 5 minuten SERVFAIL, waarvan meer dan 2 nadat de DS al was verwijderd: de resolver vertrouwde de gecachte DS tot de TTL ervan verliep. De juiste volgorde gaf helemaal geen fouten; bezoekers kregen alleen een paar minuten lang ongevalideerde antwoorden. Onze TTL was 300 seconden; in .com leeft een DS 24 uur, dus een vergeten DS na een verhuizing kan voor validerende resolvers tot een dag onbereikbaarheid betekenen.

Een DNSSEC-storing onderscheiden van andere DNS-problemen

Vraag de resolver de validatie over te slaan met +cd (checking disabled). SERVFAIL zonder die optie en een normaal antwoord met die optie betekent dat DNSSEC de boosdoener is:

$ dig @127.0.0.1 www.moved.lab A +dnssec
;; status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (validation failure <www.moved.lab. A IN>: No DNSKEY record from 127.0.22.20 for key moved.lab. while building chain of trust)
$ dig @127.0.0.1 www.moved.lab A +cd
;; status: NOERROR
;; flags: qr rd ra cd
www.moved.lab.  245 IN A 198.51.100.20

SERVFAIL ook met +cd wijst ergens anders op: servers die plat liggen of een delegatie die naar de verkeerde plek wijst. Onze uitleg over hoelang DNS-propagatie duurt en over DNS-records behandelt die gevallen.

Antwoordgrootte: ECDSA P-256 tegenover RSA 2048

Handtekeningen maken elk antwoord groter, en het algoritme maakt uit. We ondertekenden twee identieke zones: good.lab met algoritme 13 (ECDSA P-256, KSK en ZSK) en rsa.lab met algoritme 8 (RSA/SHA-256, beide sleutels 2048 bits), en maten de grootte van het gezaghebbende antwoord (dig +norec, regel MSG SIZE).

RSA-handtekeningen maken antwoorden 1,9 tot 2,8 keer groter dan ECDSA. Al onze antwoorden pasten in 1232 bytes (de gangbare EDNS-buffergrootte), maar RSA-zones met extra sleutels tijdens een sleutelwissel komen dichter bij die grens, en grote UDP-antwoorden raken vaker kwijt en worden dan via TCP opnieuw opgevraagd. De richtlijnen van de IETF: RFC 8624 (in november 2025 vervangen door RFC 9904, dat dezelfde eisniveaus overneemt) noemt algoritmen 8 en 13 MUST voor ondertekening, Ed25519 (15) RECOMMENDED en RSA/SHA-1 (5 en 7) NOT RECOMMENDED. Voor DS-records is SHA-256 (type 2) verplicht en SHA-1 (type 1) verboden. Laat je DNS-provider je kiezen, neem dan algoritme 13.

Hoeveel domeinen en resolvers DNSSEC gebruiken

• Resolvers. APNIC mat dat na de wissel van de rootsleutel op 11 oktober 2026 het aandeel gebruikers achter DNSSEC-validerende resolvers steeg van 39,7% naar 40,6% (Geoff Huston, APNIC-blog, 21 oktober 2026, in het Engels). Een DNSSEC-storing raakt dus ongeveer twee op de vijf bezoekers, niet iedereen.
• .cz-domeinen. Het register CZ.NIC toont op nic.cz 1.068.873 ondertekende domeinen van de 1.620.443, ofwel 66% (gecontroleerd op 10 november 2026).
• .nl-domeinen. SIDN meldt ruim 3,3 miljoen ondertekende domeinen van ruim 6 miljoen (sidn.nl, 10 november 2026).
• DS-TTL bij registers (hoelang je wacht na het verwijderen van een DS): 86400 seconden (24 uur) in .com (cloudflare.com op a.gtld-servers.net); landenzones kunnen korter zijn, bijvoorbeeld 10801 seconden (ongeveer 3 uur) in .ua (hostmaster.ua en cctld.ua op in1.ns.ua). Alle drie de voorbeelden gebruiken algoritme 13.

Als X, doe dan Y

Checklist voordat je van DNS-provider wisselt

1. Controleer of er een DS is: dig DS example.com +short. Lege uitvoer betekent dat DNSSEC uit staat: verhuis zoals gewoonlijk.
2. Zoek de DS-TTL in je zone op (dig DS example.com, tweede kolom; 86400 in .com).
3. Verwijder de DS bij de registrar en controleer dat dig DS example.com +short niets meer teruggeeft.
4. Wacht de DS-TTL af met marge (een hele dag voor .com). De site blijft werken, alleen zonder ad.
5. Pas nu wijzig je de nameservers van het domein en wacht je de TTL van de delegatie af.
6. Schakel ondertekening in bij de nieuwe DNS-provider, voeg de nieuwe DS toe en controleer de vlag ad.
7. Wil je ook je domeinnaam naar een andere registrar verhuizen, vraag dan eerst aan beide registrars wat er met de DS gebeurt, en voer de twee wijzigingen niet op dezelfde dag uit.

Veelgestelde vragen

Heeft een gewone website DNSSEC nodig?

Het beschermt je bezoekers tegen vervalste DNS-antwoorden en is nodig voor DANE bij e-mail. Ondertekent je DNS-provider automatisch en denk je bij een verhuizing aan de DS, dan is inschakelen de moeite waard. Zo niet, dan is per ongeluk 40% van de gebruikers buitensluiten een realistischer risico dan een aanval.

Maakt DNSSEC een site trager?

Antwoorden worden groter: 2,5 tot 3 keer met ECDSA en 5 tot 6 keer met RSA op onze testopstelling. De validatie gebeurt bij de resolver en sleutels worden gecachet, dus de laadsnelheid van pagina’s verandert nauwelijks. Laadtijden van pagina’s hebben we niet gemeten.

Waarom opent de site bij mij wel, maar bij collega’s niet?

Jouw resolver valideert misschien niet, of heeft de oude sleutels nog in de cache, zoals in onze sleuteltest. Vergelijk dig example.com @1.1.1.1 met dig example.com @1.1.1.1 +cd: het verschil laat zien of DNSSEC de oorzaak is.

Hoe snel is de site terug na het corrigeren van de DS?

Niet voordat de oude DS uit de caches van resolvers is verlopen. Op onze testopstelling herstelde de resolver zich bij een DS-TTL van 3600 seconden 52 minuten na de correctie, bij TTL 300 na 2 minuten. In .com is de DS-TTL 24 uur; Google Public DNS en Cloudflare laten je een domein handmatig uit hun cache verwijderen.