Hoe DNSSEC werkt — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC uitgelegd

DNSSEC authentiseert DNS-data door een hiërarchie van cryptografische handtekeningen die zich keten van een record in uw zone helemaal terug tot een vertrouwensanker dat hardcoded is in elke validerende resolver. Deze gids loopt door de bewegende delen — DNSKEY, DS, RRSIG, NSEC/NSEC3, en de KSK/ZSK-rollen — op een niveau dat u in staat stelt te redeneren over werkelijke deployments zonder cryptograaf te zijn.

Voor de operationele rollover-procedures (pre-publish ZSK, double-signature KSK, algoritme-rollover), ga door naar DNSSEC-sleutelbeheer. Voor de hoogniveau-introductie zonder de mechaniek, is de pagina Wat is DNSSEC? een beter startpunt.

De betrokken records

DNSSEC introduceert vier recordtypes in een ondertekende zone, plus DS-records gepubliceerd in de bovenliggende zone:

Handtekeningsleutels: KSK, ZSK, CSK

DNSSEC gebruikt historisch een twee-sleutel-splitsing: een KSK voor hoogwaardige operaties met lage frequentie, en een ZSK voor hoogfrequente operaties met lagere ceremonie. De motivatie is puur operationeel — cryptografisch doen beide sleutels hetzelfde (data ondertekenen met een privésleutel, verifiëren met een publieke).

Zone-Signing-Key (ZSK)

De ZSK ondertekent alles in uw zone behalve de DNSKEY-recordset. Wanneer een resolver de A-records van example.com opvraagt, komt het antwoord terug met een corresponderende RRSIG ondertekend door de ZSK. Elke ondertekende recordset heeft zijn eigen RRSIG.

ZSK's zijn typisch:

• Kleiner (1024-bit RSA was gebruikelijk in vroege deployments; ECDSA P-256 / 256-bit is de moderne norm)
• Relatief vaak geroteerd (elke 1–3 maanden historisch; sommige beheerders slaan nu geplande rotaties over met sterke sleutelopslag)
• Eenvoudiger te roteren omdat het DS-record van de bovenliggende zone niet hoeft te veranderen

Key-Signing-Key (KSK)

De KSK ondertekent alleen de DNSKEY-recordset. Die set bevat het publieke deel van elke actieve handtekeningsleutel in de zone. Door de DNSKEY-set te ondertekenen met de KSK, koppelt u elke andere sleutel in de zone (specifiek elke actieve ZSK) aan een sleutel waarvan de hash bij de bovenliggende zone is gepubliceerd.

KSK's zijn typisch:

• Groter (2048-bit RSA, ECDSA P-256 of Ed25519 zijn allemaal gangbaar)
• Zelden geroteerd (elke 1–5 jaar, of alleen bij vermoede compromittering)
• Duurder om te roteren omdat het DS-record bij de bovenliggende zone moet worden bijgewerkt, wat de registrar en TLD-timing erbij betrekt

Combined Signing Key (CSK)

Een CSK speelt beide rollen in een enkele sleutel. Dezelfde sleutel ondertekent DNSKEY (KSK-rol) en andere recordsets (ZSK-rol). Moderne deployments gebruiken steeds vaker CSK met ECDSA P-256 of Ed25519, omdat:

• Handtekeningen klein genoeg zijn dat de kosten per query verwaarloosbaar zijn
• Operationele complexiteit lager is (één sleutel om te beheren, één rotatie om te coördineren)
• HSM-ondersteunde sleutelopslag het beveiligingsargument om KSK en ZSK te scheiden, vermindert

DNScale gebruikt standaard CSK met ECDSA P-256 voor nieuwe zones, wat de standaard is voor de meeste moderne managed leveranciers.

DNSKEY: Publieke sleutels publiceren in de zone

Elke actieve handtekeningsleutel heeft zijn publieke deel gepubliceerd als DNSKEY-record op het zonetop:

example.com.   3600   IN   DNSKEY   257 3 13 oJMR...                        ; KSK
example.com.   3600   IN   DNSKEY   256 3 13 mZXp...                        ; ZSK

De velden gedecodeerd:

• Vlaggen (257 of 256): bit 7 (SEP — Secure Entry Point) is gezet op de KSK, wat 257 geeft. De ZSK heeft 256. Beide formaten delen ook bit 8 (Zone Key) die altijd is gezet in DNSKEY.
• Protocol (3): altijd 3 in geldige DNSSEC.
• Algoritme (13 hier): 13 = ECDSA P-256, 8 = RSA SHA-256, 15 = Ed25519. Zie IANA DNSSEC algoritmen voor de volledige lijst.
• Publieke sleutel (base64-gecodeerd): het werkelijke sleutelmateriaal.

Een validerende resolver haalt de DNSKEY-set op bij het valideren van elk record uit uw zone, en gebruikt de juiste sleutel (KSK voor de DNSKEY-RRSIG zelf, ZSK voor al het andere).

RRSIG: De handtekeningen

Elke ondertekende recordset in uw zone wordt vergezeld door een of meer RRSIG-records — één per actieve handtekeningsleutel voor die rol. Een RRSIG ziet er zo uit:

example.com.   3600   IN   A      192.0.2.1
example.com.   3600   IN   RRSIG  A 13 2 3600 20260601000000 20260501000000 12345 example.com. 4kQp...

De RRSIG-velden:

• Type covered (A): het type recordset dat wordt ondertekend.
• Algoritme (13): moet overeenkomen met het DNSKEY-algoritme.
• Labels (2): aantal labels in de oorspronkelijk ondertekende naam.
• Original TTL (3600): de TTL die de recordset had toen deze werd ondertekend.
• Handtekeningverloop (20260601000000) en begin (20260501000000): UTC-tijdstempels. De handtekening is alleen geldig in dit venster.
• Key tag (12345): korte ID voor welke DNSKEY in de zone deze handtekening produceerde. Komt overeen met de key tag van het corresponderende DNSKEY-record.
• Signer name (example.com.): de zone wiens sleutel dit ondertekende.
• Handtekening (base64-gecodeerd): de werkelijke cryptografische handtekening.

Handtekening-verloopvensters zijn waarom DNSSEC operationeel niet-triviaal is. Als uw autoritatieve server stopt met opnieuw ondertekenen van de zone — zelfs kort —, beginnen handtekeningen te verlopen, validerende resolvers beginnen SERVFAIL terug te geven, en uw domein gaat effectief offline. Managed DNS-leveranciers tekenen automatisch opnieuw; zelf-gehoste DNSSEC vereist een werkende signer-pipeline.

DS-records: De link naar de bovenliggende

Het DS (Delegation Signer)-record is het scharnier dat uw zone verbindt met de globale vertrouwensketen. Het leeft in de bovenliggende zone (.com, .eu, .de, etc.) en bevat een hash van uw KSK. U voegt het niet toe aan uw eigen zone — u publiceert het bij uw registrar, die het doorgeeft aan het TLD-register.

Een DS-record in de bovenliggende zone ziet er zo uit:

example.com.   86400   IN   DS   12345 13 2 7c89...

Velden:

• Key tag (12345): ID voor welke KSK deze DS hasht (komt overeen met de DNSKEY-key tag).
• Algoritme (13): moet overeenkomen met het DNSKEY-algoritme.
• Digesttype (2): SHA-256 (2) of SHA-384 (4) — SHA-1 (1) is verouderd.
• Digest (hex-gecodeerd): de werkelijke hash.

Wanneer een validerende resolver uw zone wil authentiseren, haalt hij het DS-record op van de bovenliggende (bv. van de .com-nameservers), haalt vervolgens uw DNSKEY-set op, berekent de hash van de overeenkomende KSK, en controleert dat deze gelijk is aan de digest in de DS. Als ze overeenkomen, vertrouwt de resolver de DNSKEY-set van uw zone, en bij uitbreiding de RRSIG's ondertekend met die sleutels.

Dit is de enige geautomatiseerde link van buiten uw zone naar het sleutelmateriaal van uw zone. Zorg dat de DS klopt of DNSSEC-validatie faalt — of erger, uw domein wordt onoplosbaar voor validerende clients.

NSEC en NSEC3: Geauthenticeerde negatie

Een subtiel maar belangrijk probleem: DNSSEC kan niet alleen de records ondertekenen die bestaan. Het moet ook bewijzen, wanneer een resolver nonexistent.example.com opvraagt, dat de naam echt niet bestaat in plaats dat het antwoord stilzwijgend wordt verworpen of vervalst.

Het mechanisme is NSEC (RFC 4034) of NSEC3 (RFC 5155).

NSEC

NSEC-records zijn alfabetisch gesorteerd en ketenen door de namen die in de zone bestaan. Bijvoorbeeld:

alpha.example.com.    NSEC  gamma.example.com.   A NSEC RRSIG
gamma.example.com.    NSEC  zulu.example.com.    A NSEC RRSIG
zulu.example.com.     NSEC  alpha.example.com.   A NSEC RRSIG     ; loopt rond naar het begin

Een resolver die beta.example.com opvraagt krijgt de ondertekende NSEC voor alpha.example.com terug, wat bewijst dat er niets is tussen alpha en gamma — dus beta bestaat niet. De handtekening op de NSEC authentiseert het negatieve antwoord.

Het nadeel: NSEC-records sommen elke naam in de zone publiek op. Iedereen die de NSEC-keten doorloopt kan een complete lijst maken van elke recordnaam. Dit heet "zone walking" en wordt soms beschouwd als een privacy-lek.

NSEC3

NSEC3 registreert dezelfde keten maar gebruikt gehashte namen in plaats van platte, plus een iteratietelling en zout:

< hash van alpha >.example.com.    NSEC3 1 0 10 abcd123...    < hash van gamma > A RRSIG NSEC3

Resolvers kunnen negatie verifiëren zoals voorheen (hash van de bevraagde naam berekenen, vinden welke NSEC3 hem dekt), maar een aanvaller kan de zone niet triviaal doorlopen — hij zou elke hash moeten kraken. NSEC3 ondersteunt ook opt-out, waarmee registers ondertekening van niet-ondertekende delegaties kunnen overslaan om niet elke niet-bestaande subzone NSEC3 te hoeven ondertekenen.

Moderne aanbeveling: NSEC3 met iteraties=0 en een vast zout (of geen zout). Hoge iteratietellingen voegen CPU-kosten toe zonder betekenisvol privacy-voordeel omdat aanvallers met GPU's elke niet-nul telling kunnen kraken. De "white lies"-aanpak (RFC 4470) is een andere manier om het zone walking-risico te verminderen terwijl de eenvoud van NSEC behouden blijft.

De validatieflow — Stap voor stap

Wat gebeurt er eigenlijk wanneer een validerende resolver een DNSSEC-ondertekend antwoord ontvangt? Bij dig +dnssec example.com @1.1.1.1:

1. De resolver ontvangt het A-record + RRSIG van uw autoritatieve server.
2. De resolver haalt de DNSKEY-set van uw zone + RRSIG op. Hij heeft nu zowel de data als de sleutels (in publieke vorm) nodig om alles te verifiëren.
3. De resolver verifieert de data-RRSIG tegen de ZSK in de DNSKEY-set. Als de handtekening ongeldig is, faalt validatie onmiddellijk.
4. De resolver verifieert de DNSKEY-RRSIG tegen de KSK in de DNSKEY-set. De KSK heeft de DNSKEY-recordset ondertekend, inclusief de ZSK. Deze stap verbindt de ZSK aan de KSK.
5. De resolver haalt het DS-record op uit de bovenliggende zone (bv. van de .com-nameservers). De DS bevat een hash van de KSK.
6. De resolver berekent de hash van de KSK en vergelijkt deze met de DS. Als ze overeenkomen, heeft de bovenliggende bevestigd welke KSK gezaghebbend is voor uw zone.
7. De resolver herhaalt de keten bij de bovenliggende. Het DS-record zelf is ondertekend door de ZSK van de bovenliggende zone; de DNSKEY-set van de bovenliggende is ondertekend door de KSK van de bovenliggende; de KSK van de bovenliggende is gehasht in het DS van de groot-bovenliggende zone, enzovoort, tot aan de root.
8. Bij de root vergelijkt de resolver de hash van de root-KSK met het vertrouwensanker dat hij hardcoded heeft (of automatisch geüpdatet via RFC 5011). De huidige root-KSK is gepubliceerd op https://data.iana.org/root-anchors/.

Als elke handtekening verifieert en de root teruggekoppeld is naar het vertrouwensanker, geeft de resolver het antwoord terug met de AD (Authenticated Data)-vlag gezet. Elke fout onderweg en de resolver geeft SERVFAIL terug — beter breken dan een mogelijk gemanipuleerd antwoord aanbieden.

Wat fout kan gaan

De eerste twee — verouderde DS en verlopen handtekeningen — veroorzaken de overgrote meerderheid van werkelijke DNSSEC-storingen. Managed leveranciers handelen herondertekening automatisch af; het DS-record bij de registrar is het door mensen aanraakbare faalpunt.

Het samenstellen — Een mentaal model

De schijnbare complexiteit van DNSSEC is meestal boekhouding. De werkelijke cryptografische vraag is eenvoudig: kwam dit antwoord van iemand die de privésleutel van de zone beheert? De vertrouwensketen is een reeks publieke-sleutel-bindingen, elk een normale "sleutel A ondertekent sleutel B" of "sleutel A ondertekent data D"-stap:

• De root-KSK ondertekent de root-DNSKEY-set (die de root-ZSK bevat).
• De root-ZSK ondertekent de DS-records van TLD's.
• De KSK van een TLD ondertekent de DNSKEY-set van de TLD (die de ZSK van de TLD bevat).
• De ZSK van de TLD ondertekent de DS-records van geregistreerde zones.
• De KSK van uw zone ondertekent uw DNSKEY-set (die uw ZSK bevat).
• Uw ZSK ondertekent elke recordset in uw zone — inclusief de NSEC/NSEC3-records die negatie afhandelen.

Elke schakel is gewoon een handtekening; de magie is dat de resolver alleen de rootsleutel nodig heeft om ze allemaal te verifiëren.

Referenties

• RFC 4033 — DNS Security Introduction and Requirements
• RFC 4034 — Resource Records for the DNS Security Extensions (DNSKEY, DS, NSEC, RRSIG)
• RFC 4035 — Protocol Modifications for the DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 7344 / 8078 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8901 — Multi-Signer DNSSEC Models
• IANA DNSSEC Algorithm Numbers
• IANA Root Trust Anchors

Gerelateerde lectuur

• Wat is DNSSEC? — top-of-funnel-introductie
• DNSSEC-sleutelbeheer — operationele rotatieprocedures
• DNSSEC-installatiehandleiding voor DNScale — productwalkthrough
• DNSSEC vs DNS over HTTPS — integriteit vs privacy
• DNS-cache-poisoning — de aanval die DNSSEC verslaat
• NIS2 en DNS-naleving — DNSSEC als regelgevende controle