DNSSEC inschakelen: de twee stappen die je nooit mag overslaan
Schakel DNSSEC in door eerst je zone te ondertekenen bij je DNS-provider en vervolgens de DS-gegevens bij je registrar te publiceren: vergeet die tweede stap niet. Een verkeerde of ontbrekende DS-koppeling leidt tot SERVFAIL bij validerende resolvers, dus test altijd met Dnsviz of dig +cd voordat je live gaat. Laat je dit liever uitvoeren, dan nemen wij die hele keten voor onze rekening.
Kort samengevat:
- Bij moderne dienstverleners voor DNS kies je automatische sleutelrotatie en zoneondertekening; handmatig sleutelbeheer vergroot de kans op verlopen handtekeningen die pas na klachten opvallen.
- Controleer of je registrar DS accepteert of juist een DNSKEY, want invoer van het verkeerde recordtype kan de vertrouwensketen breken.
- Controleer vooraf of naamservers, firewalls en verkeersverdelers EDNS0 ondersteunen; anders kunnen grote antwoorden via UDP websites onbereikbaar maken wanneer TCP geen terugval biedt.
- Schakel je DNSSEC uit, verwijder dan eerst de DS-vermelding bij de registrar en wacht tot de oude TTL is verstreken voordat je de ondertekening verwijdert.
Inhoudsopgave
- Stap voor stap: domeinzone ondertekenen bij je DNS-provider
- DS-records publiceren bij je registrar: zo koppel je de keten
- Controle en testen: commando’s en tools voor validatie
- Veelvoorkomende foutoorzaken en snelle herstelstappen
- Hoe wij bij NLXS DNS en DNSSEC uit handen nemen
- Verschillende typen DNSSEC-records en hun functies
- Ondersteuning van DNSSEC bij DNS-providers en hostingpartijen
- Compatibiliteit van DNSSEC met je bestaande infrastructuur
- Back-out procedures: DNSSEC veilig weer uitschakelen
- Impact van DNSSEC op prestaties en caching
- Zelf uitvoeren of uitbesteden: een eerlijke afweging
- NLXS regelt DNSSEC veilig en zonder gedoe
- Veelgestelde vragen
- Bronnen
Stap voor stap: domeinzone ondertekenen bij je DNS-provider
Ondertekenen gebeurt met twee sleutelparen: de Key Signing Key (KSK) ondertekent de sleutelset zelf, terwijl de Zone Signing Key (ZSK) de losse records van je zone signeert. De KSK wissel je zelden, de ZSK roteert vaker en automatisch. Bij de meeste moderne DNS-providers hoef je dit onderscheid niet handmatig te beheren: inline-signing of een dnssec-policy regelt sleutelgeneratie en vernieuwing zelf, en dat is ook wat we aanraden tenzij je een specifieke reden hebt om sleutels handmatig te beheren.
De activering verloopt meestal in deze volgorde:
- Open het beheerpaneel van je DNS-provider en zoek de optie voor DNSSEC of zone-ondertekening.
- Kies voor een automatisch beleid (bijvoorbeeld een dnssec-policy in BIND of
pdnsutil secure-zonebij PowerDNS) in plaats van handmatig sleutelbeheer. - Laat de provider de DNSKEY- en RRSIG-records genereren en publiceren in je zone.
- Controleer of je provider CDS- en CDNSKEY-records aanbiedt, zodat de volgende stap grotendeels automatisch kan verlopen.
Niet elke provider ondersteunt CDS/CDNSKEY-automatisering, dus controleer dit voordat je verdergaat naar de registrar. Zonder die ondersteuning blijft publicatie bij de registrar een handmatige stap.
Pro-tip: Kies waar mogelijk voor automatische sleutelrotatie in plaats van handmatige KSK/ZSK-wissels: dat voorkomt de meeste verlopen handtekeningen die beheerders pas merken als klanten al klagen.
Wil je niet zelf in een beheerpaneel duiken, dan regelen wij ondertekening en sleutelbeheer als onderdeel van onze DNS-beheer voor bedrijven.
DS-records publiceren bij je registrar: zo koppel je de keten
Zodra je zone is ondertekend, moet de bovenliggende zone weten dat die ondertekening bestaat. Dat gebeurt via een Delegation Signer (DS) record, dat de registry via je registrar publiceert. Sommige registrars vragen je de DS-waarden zelf in te voeren, andere accepteren direct de DNSKEY en berekenen de DS zelf. Het verschil is belangrijk: plak je het verkeerde recordtype in het verkeerde veld, dan ontstaat een mismatch die de hele keten kan breken, zoals ook blijkt uit de uitleg over DS-records.
Wat je meestal nodig hebt om te plakken of te uploaden:
- Het Key Tag, een kort nummer dat de specifieke sleutel identificeert.
- Het algoritme-nummer van de gebruikte sleutel (meestal 8 voor RSA/SHA-256 of 13 voor ECDSA).
- Het digest-type, waarbij we aanraden altijd SHA-256 te kiezen in plaats van het verouderde en zwakkere SHA-1.
- De digest-waarde zelf, een lange hexadecimale string die je DNS-provider aanlevert.
Steeds meer registrars en registries ondersteunen CDS- en CDNSKEY-automatisering volgens RFC 7344 en RFC 8078, waarbij de child-zone zelf signaleert welke DS-gegevens moeten gelden. Dat scheelt een handmatige invoerstap en voorkomt typefouten, die als belangrijkste oorzaak van mislukte DNSSEC-activeringen worden gezien. Werk je met domeinregistratie via een derde partij, lees dan ook onze uitleg over hoe domeinregistratie zakelijk werkt voor de rol die je registrar hierin speelt.
Controle en testen: commando’s en tools voor validatie
Voordat je DNSSEC als voltooid beschouwt, test je de keten grondig. Een dig +dnssec tegen je eigen nameserver laat zien of RRSIG-records daadwerkelijk worden teruggegeven. Een dig +cd (checking disabled) tegen een validerende resolver zoals 8.8.8.8 geldt als een betrouwbare manier om te bepalen of een storing door DNSSEC-validatie komt: krijg je met +cd wel een antwoord maar zonder die vlag een SERVFAIL, dan zit het probleem gegarandeerd in de ondertekeningsketen, zoals ook Cloudflare’s eigen troubleshooting-documentatie bevestigt.
Gebruik daarnaast:
- dnsviz.net voor een visuele weergave van de volledige keten, inclusief DS-match en RRSIG-geldigheid.
- Verisign DNSSEC Debugger voor een tweede, onafhankelijke validatie van dezelfde zone.
- Extended DNS Errors (EDE) in resolver-responses, die specifieke codes zoals “DNSSEC Bogus” of “RRSIGs Missing” teruggeven.
EDE-codes maken troubleshooting aanzienlijk gerichter, aldus onderzoek van RIPE Labs: in plaats van te gokken welke laag faalt, wijst de foutcode direct naar de oorzaak.
Veelvoorkomende foutoorzaken en snelle herstelstappen
De meeste DNSSEC-problemen vallen terug op een klein aantal oorzaken. Herken je het patroon, dan is herstel meestal snel.
- Een DS/DNSKEY-mismatch ontstaat wanneer de gepubliceerde DS niet overeenkomt met de actieve sleutel: vergelijk beide waarden handmatig of met dnsviz.net en corrigeer de DS bij je registrar.
- Verlopen RRSIG’s ontstaan bij mislukte sleutelrotatie: een pre-publish of double-signing aanpak voorkomt dat de oude handtekening verloopt voordat de nieuwe actief is.
- “No Reachable Authority”-meldingen wijzen meestal op EDNS-incompatibiliteit of een nameserver die grote UDP-pakketten blokkeert: controleer firewallregels en EDNS-ondersteuning per authoritative server.
Pro-tip: Bewaar een werkende DS-waarde apart voordat je een sleutelrollover start, zodat je bij problemen direct kunt terugvallen op de laatst bevestigde configuratie.
Hoe wij bij NLXS DNS en DNSSEC uit handen nemen
We merken dat veel beheerders DNSSEC technisch wel begrijpen, maar het risico op een verkeerde DS-publicatie liever niet zelf dragen. Daarom verzorgen we ondertekening, DS-publicatie en doorlopende monitoring als vast onderdeel van ons DNS-beheer, met dezelfde snelle opvolging die onze klanten van ons gewend zijn bij andere ICT-problemen.
Concreet nemen we het volgende over:
- Sleutelbeheer en automatische rollovers, zodat RRSIG’s nooit ongemerkt verlopen.
- DS-publicatie bij de registrar, inclusief controle op digest-type en algoritme.
- Doorlopende monitoring van de ondertekeningsketen met directe melding bij afwijkingen.
- Snelle interventie bij storingen, in lijn met onze aanpak voor DNS-problemen binnen een uur oplossen.
Verschillende typen DNSSEC-records en hun functies
DNSSEC voegt een beperkt aantal nieuwe recordtypen toe aan een zone, elk met een eigen taak in de keten van vertrouwen. Het DNSKEY-record bevat de publieke sleutel waarmee andere records worden geverifieerd. Het RRSIG-record is de digitale handtekening die bij elke set records hoort en bewijst dat de inhoud niet is gemanipuleerd. Het DS-record (Delegation Signer) ligt bij de bovenliggende zone en vormt de brug tussen ouder- en kindzone: zonder dit record kan een resolver de handtekening van je zone niet vertrouwen.
Daarnaast bestaan NSEC en NSEC3, die bewijzen dat een bepaald record niet bestaat. Dat klinkt overbodig, maar is nodig om zogeheten “negatieve antwoorden” (zoals bij een niet-bestaand subdomein) ook cryptografisch te kunnen verifiëren. NSEC3 voegt hashing toe om het opsommen van alle records in een zone lastiger te maken, wat de voorkeur heeft boven het oudere NSEC bij nieuwere implementaties.
Voor meer achtergrond bij deze recordtypen en hoe ze samen een zone opbouwen, verwijzen we naar onze uitleg over DNS-records en hoe je ze instelt. Elk van deze records werkt alleen samen: een DNSKEY zonder bijbehorende DS bij de registrar laat de keten onvolledig, ongeacht hoe correct de rest van je configuratie is.
Ondersteuning van DNSSEC bij DNS-providers en hostingpartijen
Niet elke DNS-provider of hostingpartij biedt dezelfde mate van DNSSEC-ondersteuning. De meeste grote, moderne platforms zoals BIND en PowerDNS hebben ingebouwde functies voor automatische sleutelvernieuwing en beleidsgebaseerde ondertekening, en bij deze software is “dnssec-validation auto” inmiddels een gangbare standaardinstelling, zoals ook SIDN’s documentatie over DNSSEC-validatie beschrijft. Bij dit soort software ligt de keuze vooral bij jou als beheerder: zet je de validatie en ondertekening aan, en controleer je de trust-anchor-instellingen.
Bij kleinere of verouderde hostingpakketten ontbreekt DNSSEC-ondersteuning soms volledig, of is het alleen beschikbaar als losse, handmatig te configureren functie. Dat maakt het verstandig om vooraf te controleren of je huidige DNS-provider zowel ondertekening als CDS/CDNSKEY-automatisering aanbiedt, voordat je met een activatie begint. Ontbreekt die ondersteuning, dan is verhuizen naar een provider die dit wel biedt vaak de snelste weg vooruit: iets waar we bij een bestaande website verhuizen rekening mee houden.
Compatibiliteit van DNSSEC met je bestaande infrastructuur
DNSSEC voegt cryptografische handtekeningen toe aan bestaande DNS-records en vereist daarom software die deze uitbreidingen begrijpt. De belangrijkste vereiste is EDNS0-ondersteuning: omdat ondertekende antwoorden groter zijn dan klassieke DNS-pakketten, moeten nameservers, firewalls en load balancers grotere UDP-pakketten kunnen verwerken of automatisch terugvallen op TCP. Verouderde netwerkapparatuur die EDNS blokkeert, is een van de meest voorkomende oorzaken van onbereikbaarheid na een DNSSEC-activatie.
Verder moet elke partij in de keten, van je DNS-provider tot je registrar en de registry van je domeinextensie, DNSSEC daadwerkelijk ondersteunen. Mist een van deze schakels die ondersteuning, dan kun je de zone wel ondertekenen, maar niet volledig activeren. Controleer dit dus aan beide kanten voordat je begint, zeker als je werkt met een registrar die los staat van je hostingpartij.
Voor bestaande websites en applicaties verandert er functioneel niets aan hoe bezoekers je site bereiken: DNSSEC beveiligt de DNS-opzoeking zelf, niet het verkeer naar je webserver, iets wat je ook zeker goed wilt regelen via Website aanmelden zoekmachines: praktische gids voor MKB. Wel is het verstandig om wijzigingen eerst in een testomgeving te valideren voordat je ze op je productiezone toepast, vooral bij complexere opzetten met meerdere nameservers of een CDN.
Back-out procedures: DNSSEC veilig weer uitschakelen
Soms is uitschakelen de juiste keuze, bijvoorbeeld bij een hardnekkige configuratiefout die je niet snel kunt oplossen. De veilige volgorde is het omgekeerde van activeren. Verwijder eerst het DS-record bij je registrar en wacht tot deze wijziging volledig is doorgevoerd bij de registry, voordat je de ondertekening bij je DNS-provider verwijdert.
Verwijder je eerst de ondertekening bij je provider terwijl de DS-record nog bij de registry staat, dan ontstaat precies het mismatch-scenario dat we eerder beschreven: validerende resolvers blijven een handtekening verwachten die niet meer bestaat, met SERVFAIL tot gevolg. Wacht daarom altijd tot de TTL van het oude DS-record is verstreken voordat je de rest van de ondertekening opruimt.
Een tijdelijke uitschakeling is soms te verkiezen boven een permanente: sommige providers bieden de mogelijkheid om de zone “unsigned” te laten publiceren terwijl de sleutels bewaard blijven, zodat je later zonder nieuwe sleutelgeneratie opnieuw kunt activeren.
Impact van DNSSEC op prestaties en caching
DNSSEC vergroot de omvang van DNS-antwoorden, omdat elk antwoord nu ook een of meer RRSIG-handtekeningen bevat. In de praktijk merken bezoekers hier weinig van: de extra data zorgt voor iets grotere pakketten, maar resolvers cachen ondertekende records net als gewone DNS-records, inclusief de bijbehorende handtekeningen. Zolang EDNS correct is geconfigureerd, blijft de opzoektijd voor een eindgebruiker vrijwel ongewijzigd.
Waar prestaties wel een rol spelen, is bij de rekenlast voor je DNS-provider: het ondertekenen van records bij elke wijziging kost rekenkracht, vooral bij zones met veel records of frequente updates. Bij de meeste moderne, beheerde DNS-platforms is dit geen zichtbaar probleem, omdat ondertekening geautomatiseerd en geoptimaliseerd verloopt. Caching-gedrag verandert dus nauwelijks, zolang je resolver-instellingen en TTL-waarden consistent blijven met je niet-ondertekende configuratie.
Zelf uitvoeren of uitbesteden: een eerlijke afweging
Zelf DNSSEC inschakelen werkt goed als je tijd hebt voor een gecontroleerde testfase en een rollbackplan klaar hebt liggen voordat je live gaat. Heb je die tijd niet, of weegt het risico op een gemiste DS-publicatie zwaarder dan de besparing, dan is uitbesteden vaak de verstandigere keuze. Beide routes zijn legitiem: het hangt af van hoeveel risico je zelf wilt dragen.
— Ken
NLXS regelt DNSSEC veilig en zonder gedoe
We nemen de volledige DNSSEC-keten uit handen: van ondertekening tot DS-publicatie en doorlopende monitoring, zodat je zelf nooit een DS-upload hoeft te vergeten.
- Direct persoonlijk contact bij vragen of een storing, zonder lange wachttijden.
- Monitoring die afwijkingen signaleert voordat bezoekers er last van hebben.
- Onderdeel van ons bredere DNS-beheer voor bedrijven, zonder verrassingen in de rekening.
Wil je weten wat dit voor jouw domein betekent? Neem contact met ons op via onze webhosting-pagina en we denken direct mee.
Veelgestelde vragen
Hoe kan ik DNSSEC testen na activatie?
Gebruik dig +dnssec tegen je eigen nameserver om te controleren of RRSIG-records worden teruggegeven, en vergelijk dit met een dig +cd tegen een publieke resolver. Online tools zoals dnsviz.net en de Verisign DNSSEC Debugger geven een volledig visueel overzicht van de keten, inclusief eventuele DS-mismatches.
Is DNSSEC belangrijk voor mijn domein?
DNSSEC voegt cryptografische handtekeningen toe aan je DNS-records en voorkomt daarmee dat bezoekers naar een vervalste versie van je zone worden geleid, zoals beschreven in ICANN’s advies over DS-recordautomatisering. Voor domeinen die gevoelige gegevens verwerken of veel vertrouwen van bezoekers vragen, is het een waardevolle aanvullende beveiligingslaag.
Welke DNS-instellingen heb ik nodig voor DNSSEC?
Je hebt een DNS-provider nodig die zone-ondertekening ondersteunt, bij voorkeur met automatische sleutelrotatie via een dnssec-policy, en een registrar die DS- of DNSKEY-publicatie accepteert. Ondersteunt je provider CDS/CDNSKEY-automatisering, dan verloopt de koppeling tussen beide grotendeels zonder handmatige invoer.
Hoe werkt DNSSEC activeren bij een hostingpartij zoals Mijndomein?
Bij de meeste Nederlandse hostingpartijen schakel je DNSSEC in via het beheerpaneel van je domein, waarna de provider automatisch de benodigde DNSKEY- en RRSIG-records genereert. Je blijft zelf verantwoordelijk voor het controleren of de DS-gegevens daadwerkelijk bij de registry zijn gepubliceerd, aangezien dit de stap is die het vaakst wordt overgeslagen.
Bronnen
- SAC126 — Executive Summary for DNSSEC Delegation Signer (DS) Record Automation
- DNS record types — DS record
- Extended DNS Errors — RIPE Labs
Reacties0
Nog geen reacties
Deel als eerste uw gedachten.
Meld u aan of registreer u om een reactie te plaatsen.