Wat is DNSSEC? Een eenvoudige gids voor DNS-beveiliging

DNSSEC — afkorting van DNS Security Extensions — is de enige breed uitgerolde verdediging tegen DNS-cache-poisoning, de aanval die een netwerktegenstander toelaat te liegen tegen resolvers over waar uw domein heenwijst. Het is sinds 2005 een standaard, elke grote TLD ondertekent nu zijn zone, en elke grote managed DNS-leverancier ondersteunt het. Als DNSSEC niet is ingeschakeld op uw publiek domein, vertrouwt u erop dat niemand tussen uw gebruikers en uw autoritatieve nameserver de middelen of motivatie heeft om hen om te leiden naar een kwaadaardige plek. Dat is een weddenschap die niet meer redelijk is.

Deze gids is het toegankelijke startpunt: wat DNSSEC daadwerkelijk doet, waarom het bestaat, hoe de vertrouwensketen op hoog niveau werkt, en wat u moet verwachten van uw DNS-leverancier. Voor de operationele mechaniek — KSK vs ZSK-rollen, sleutelrotaties, algoritmekeuzes — lees de diepere gids DNSSEC-sleutelbeheer zodra u de basis kent.

Wat DNSSEC doet (en niet doet)

DNSSEC voegt digitale handtekeningen toe aan DNS-records. Wanneer uw autoritatieve nameserver een A-record teruggeeft dat zegt dat example.com zich op 192.0.2.1 bevindt, geeft hij ook een cryptografische handtekening over dat record terug. Een resolver die DNSSEC-validatie ondersteunt kan de handtekening controleren tegen de publieke sleutel van uw zone — en die publieke sleutel controleren tegen een keten die helemaal teruggaat tot een hardcoded vertrouwensanker — en het antwoord weigeren als de handtekeningen niet valideren.

Dat is de hele taak. DNSSEC:

• ✅ Bewijst dat het antwoord van de juiste autoritatieve server komt. Een man-in-the-middle-aanvaller kan geen record vervalsen zonder de handtekening te breken.
• ✅ Detecteert manipulatie op de draad of in een cache. Zelfs als de cache van een resolver is vergiftigd, valideren de handtekeningen niet.
• ✅ Bewijst dat een record niet bestaat (negatieve antwoorden worden ook ondertekend, via NSEC/NSEC3-records).

DNSSEC niet:

• ❌ Versleutelt DNS-queries of -antwoorden. Iedereen die het netwerk bekijkt kan nog steeds zien wat u opzoekt. Gebruik DNS over HTTPS of DNS over TLS daarvoor.
• ❌ Verbergt de structuur van uw zone. DNSSEC-handtekeningen zijn publiek; iedereen kan ze ophalen.
• ❌ Vervangt TLS of HTTPS. DNSSEC beschermt DNS zelf; zodra u een IP-adres heeft, ligt de beveiliging van de verbinding bij het applicatieprotocol.
• ❌ Verdedigt tegen gecompromitteerde autoritatieve servers. Als een aanvaller uw nameserver beheert, kan hij ondertekenen wat hij wil met de privésleutels van uw zone. DNSSEC vertrouwt de sleutelhouder.

Waarom DNSSEC bestaat — Het cache-poisoning-probleem

Het oorspronkelijke DNS-protocol uit de jaren 80 was ontworpen voor een netwerk waarin niemand actief probeerde te bedriegen. Resolvers vroegen autoritatieve servers om antwoorden in plain UDP, en vertrouwden alles wat terugkwam zolang de bron-IP en een 16-bit transactie-ID overeenkwamen.

Dat vertrouwensmodel hield stand tot 2008, toen Dan Kaminsky praktische cache-poisoning op grote schaal demonstreerde. De aanval werkt zo:

1. De aanvaller laat een recursieve resolver een naam opzoeken die hij beheert (anything.example.com).
2. Terwijl de resolver wacht op een antwoord van de autoritatieve server, overspoelt de aanvaller hem met vervalste antwoorden waarbij hij de 16-bit transactie-ID raadt.
3. Als een vervalst antwoord de race wint, cachet de resolver het antwoord van de aanvaller — een vals A-record voor example.com — en bedient het aan elke volgende query gedurende de hele TTL.

Elke gebruiker van die resolver — potentieel miljoenen mensen — wordt nu stilzwijgend omgeleid naar waar de aanvaller koos. Webverkeer, e-mail, software-updates: alles wordt gerouteerd naar de server van de aanvaller totdat de slechte cache-entry verloopt.

De DNS-gemeenschap reageerde met drie lagen mitigatie:

1. Bronpoort-randomisering bij resolvers (RFC 5452, 2009) — maakte de race veel moeilijker door 16 extra bits onvoorspelbaarheid toe te voegen.
2. DNS over HTTPS / DNS over TLS op de resolver-naar-client-hop — versleutelde het gesprek zodat een aanvaller op het lokale netwerk queries niet kan zien of wijzigen.
3. DNSSEC op de autoritatief-naar-resolver-hop — voegde cryptografische handtekeningen toe zodat een vergiftigde cache ongeldige handtekeningen produceert die een validerende resolver afwijst.

DNSSEC is de enige van de drie die het onderliggende probleem op autoritatief niveau echt oplost. Bronpoort-randomisering maakt de aanval moeilijker; DoH/DoT verandert wie de query kan zien maar niet wie kan liegen over het antwoord. DNSSEC verifieert het antwoord zelf.

De vertrouwensketen — Een hoogniveau-overzicht

Wat DNSSEC op internetschaal laat werken is dat resolvers uw specifieke publieke sleutel niet vooraf hoeven te kennen. In plaats daarvan lopen ze een vertrouwensketen van een hardcoded rootsleutel tot uw zone:

Rootzone (.)
    │  ondertekent met root-KSK
    │  publiceert DS-record voor .com in de root
    ▼
.com TLD
    │  ondertekent met .com-KSK
    │  publiceert DS-record voor example.com in .com
    ▼
example.com
    │  ondertekent alle records met eigen sleutels
    │  handtekening op het gevraagde record
    ▼
A-record: example.com → 192.0.2.1

Een validerende resolver volgt deze keten omgekeerd:

1. Hij ontvangt het ondertekende A-record van uw autoritatieve server.
2. Hij haalt het DS-record voor example.com op van de .com-nameservers en controleert dat de hash overeenkomt met de KSK van uw zone.
3. Hij haalt het DS-record voor .com op van de root-nameservers en controleert de hash tegen de KSK van de .com-zone.
4. Hij controleert de handtekening van de rootzone tegen het hardcoded vertrouwensanker (de root-KSK, ook gepubliceerd door IANA op https://data.iana.org/root-anchors/).

Als een schakel in de keten faalt te verifiëren, wordt het antwoord behandeld als niet-vertrouwd. De meeste validerende resolvers zullen SERVFAIL teruggeven in plaats van een mogelijk gemanipuleerd antwoord aan te bieden.

U hoeft de mechaniek niet te begrijpen om DNSSEC te gebruiken. Uw DNS-leverancier genereert en roteert sleutels voor u; uw enige taak is een stuk publiceren — het DS-record — bij uw registrar zodat de keten uw zone bereikt.

Voor de volledige mechanische uitsplitsing — KSK vs ZSK-rollen, RRSIG-records, NSEC/NSEC3 voor geauthenticeerde negatie — zie Hoe DNSSEC werkt.

Hoe te zien of een domein DNSSEC heeft

Voer dig uit met de +dnssec-vlag tegen een validerende resolver:

dig +dnssec example.com @1.1.1.1

Zoek twee dingen:

1. RRSIG-records in de antwoordsectie, gekoppeld aan elke bevraagde recordset. Dat zijn de handtekeningen.
2. De AD-vlag (Authenticated Data) in de antwoordheader, die aangeeft dat de resolver de keten succesvol heeft gevalideerd.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                ^^
                                 │
                          AD-vlag gezet = validatie geslaagd
 
;; ANSWER SECTION:
example.com.         300  IN  A      192.0.2.1
example.com.         300  IN  RRSIG  A 13 2 300 20260601000000 ...
                                         ^^
                                          │
                                   handtekeningrecord

Als u de RRSIG's ziet maar geen AD-vlag, valideert de resolver niet — probeer 1.1.1.1 of 9.9.9.9, beide valideren standaard. Als u geen RRSIG's ziet, is de zone niet ondertekend.

Voor visualisatie tekenen DNSViz en de Verisign DNSSEC Debugger de volledige vertrouwensketen en lichten breuken uit.

Wanneer DNSSEC inschakelen

Kort gezegd: altijd, voor elk publiek domein.

Specifieke gevallen waar het bijzonder belangrijk is:

• Hoog-vertrouwen-diensten — bankieren, e-commerce, identity providers, overheid — waar een succesvolle cache-poisoning-aanval directe gevolgen heeft.
• E-mail — DNSSEC is een vereiste voor DANE/TLSA, dat SMTP-TLS beschermt tegen downgrade-aanvallen. MTA-STS is een gedeeltelijk alternatief voor organisaties die nog niet klaar zijn voor DANE.
• EU-gereguleerde entiteiten onder NIS2 — Artikel 21(2)(h) vereist "beleid en procedures betreffende het gebruik van cryptografie". Een DNS-leverancier die geen DNSSEC aanbiedt, of een deployment die het niet heeft ingeschakeld, loopt het risico als niet-conform beoordeeld te worden. Zie de NIS2 en DNS-gids voor de volledige toewijzing.
• Compliance-gedreven omgevingen — PCI DSS, HIPAA, ISO 27001 en diverse nationale kaders noemen DNSSEC als aanbevolen of verwachte controle.

Er zijn in wezen geen situaties waarin DNSSEC een slecht idee is voor een publieke zone. De historische bezwaren — operationele complexiteit, sleutelbeheerrisico, resolver-compatibiliteit — zijn grotendeels opgelost door managed DNS-leveranciers die sleutelgeneratie, -rotatie en DS-publicatie automatisch afhandelen.

Waar te zoeken in een DNSSEC-bekwame DNS-leverancier

Bij het beoordelen van de DNSSEC-ondersteuning van een DNS-leverancier, vraag:

DNSSEC inschakelen op DNScale

DNScale schakelt DNSSEC met één klik per zone in:

1. Open vanuit het dashboard de zone.
2. Klik op DNSSEC inschakelen. DNScale genereert een CSK (Combined Signing Key) met ECDSA P-256.
3. Kopieer het weergegeven DS-record naar uw registrar. Sommige registrars accepteren het direct; sommige via API; sommige vereisen nog handmatige invoer.
4. Wacht 24–48 uur tot de DS zich verspreidt op de TLD.
5. Verifieer met dig +dnssec uwdomein @1.1.1.1 en bevestig de AD-vlag.

Sleutelrotatie, handtekeningverversing en synchronisatie met de bovenliggende zone gebeuren automatisch. Algoritme-upgrades zijn gecoördineerde rolls die DNScale uitvoert zonder klant-zichtbare downtime.

Voor de volledige stap-voor-stap inclusief registrar-specifieke instructies, zie DNSSEC-installatiehandleiding voor DNScale. Voor de onderliggende mechaniek, zie Hoe DNSSEC werkt en DNSSEC-sleutelbeheer.

Referenties

• RFC 4033 — DNS Security Introduction and Requirements
• RFC 4034 — Resource Records for the DNS Security Extensions
• RFC 4035 — Protocol Modifications for the DNS Security Extensions
• RFC 5155 — DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 8901 — Multi-Signer DNSSEC Models
• IANA Root Zone Trust Anchors
• DNSViz — visualizer voor DNSSEC-vertrouwensketens
• Verisign DNSSEC Debugger

Gerelateerde lectuur

• Hoe DNSSEC werkt — KSK/ZSK/DS/DNSKEY-mechaniek
• DNSSEC-sleutelbeheer — operationele rotatieprocedures
• DNSSEC-installatiehandleiding voor DNScale — productwalkthrough
• DNSSEC vs DNS over HTTPS — integriteit vs privacy
• NIS2 en DNS-naleving — regelgevende toewijzing
• DNS-cache-poisoning — de aanval die DNSSEC verslaat