Het Domain Name System is het adresregister van elke digitale dienst; zonder betrouwbare resolutie stopt identiteitsbeheer, e-mailafhandeling en burgerportalen binnen seconden. Het oorspronkelijke protocol werd echter ontworpen zonder aandacht voor authenticiteit of vertrouwelijkheid, waardoor cache poisoning, DNS-hijacking, spoofing van certificaatketens en privacygevoelige inzage in onbeveiligde query’s nog steeds dagelijkse risico’s vormen. Aanvallen op Dyn in 2016, maar ook recente campagnes waarbij registrars van gemeentelijke domeinen werden misbruikt, tonen aan dat verstoringen niet alleen commerciële platforms raken maar net zo makkelijk DigiD-ketens, uitgifteportalen of OT-beheerinterfaces kunnen platleggen. Bovendien verplichten de BIO, NIS2 en Wbni tot aantoonbare maatregelen om DNS als vitale schakel van de beschikbaarheid te borgen.
Voor Nederlandse overheidsorganisaties betekent dat een gelaagde aanpak: DNSSEC om herkomst van records cryptografisch te bewijzen, DNS-over-HTTPS om gevoelige queries te versleutelen, en protective DNS om bekende dreigingen op resolver-niveau af te klemmen. Deze gids beschrijft hoe infrastructuur- en securityteams de volledige keten ontwerpen, implementeren en monitoren. Daarbij koppelen we technische stappen aan change-governance, logging voor ENSIA-rapportages en incidentrespons-playbooks, zodat DNS-beveiliging geen losse workshop blijft maar een structurele capability binnen de Nederlandse Baseline voor Veilige Cloud.
Ontwerp één referentiearchitectuur waarin DNSSEC-validatie op alle resolvers verplicht is, DoH uitsluitend via goedgekeurde eindpunten verloopt en protective DNS-policy’s via DHCP, VPN en MDM worden afgedwongen. Leg key-rotaties, DS-updates en telemetrie voor DNS vast in hetzelfde changeproces zodat auditors exact kunnen volgen waarom en wanneer een wijziging is uitgevoerd.
Activeer DNSSEC-validatie eerst op alle recursive resolvers voordat je eigen zones ondertekent. Zo blijft cache poisoning direct buiten de deur en heb je tijd om signing te oefenen, DS-records bij de registrar te testen en changeprocedures te verfijnen voordat burgers en ketenpartners afhankelijk worden van jouw sleutelbeheer.
DNSSEC en DNS-over-HTTPS: authenticiteit en vertrouwelijkheid
DNSSEC voegt cryptografische waarborgen toe aan een protocol dat oorspronkelijk alleen op vertrouwen rustte. Door de rootzone, top-level domains en elke organisatiezone in een keten van ondertekeningen op te nemen, kan een resolver verifiëren dat een antwoord werkelijk van de autoritatieve bron afkomstig is en onderweg niet is gewijzigd. Voor de Nederlandse overheid betekent dit dat burgerportalen, DigiD-koppelingen en SharePoint-omgevingen niet meer afhankelijk zijn van kwetsbare, onbevestigde records. Een valide handtekening blokkeert cache poisoning en spoofing doordat valse antwoorden onmiddellijk worden verworpen.
Validatie en signing vullen elkaar aan maar leveren verschillende voordelen. Door eerst DNSSEC-validatie op alle recursive resolvers in gemeentelijke datacenters, Rijksclouds, Entra Private DNS en OT-netwerken te activeren, worden gebruikers direct beschermd tegen aanvallen op externe domeinen. Pas daarna loont het om de eigen zones te ondertekenen zodat ook burgers en ketenpartners profiteren. Deze volgorde sluit aan op de BIO-paragraaf voor wijzigingsbeheer: iedere stap levert aantoonbare risicoreductie op en kan apart worden getest, gelogd en goedgekeurd door de CAB.
Het ondertekenen van overheidszones vraagt een strak proces dat prima te automatiseren is in Azure DNS of bij een registrar. Teams genereren een Zone Signing Key voor dagelijkse ondertekening en een Key Signing Key die als trust anchor dient. Daarna worden DS-records bij de registrar gepubliceerd en wordt elke zone opnieuw uitgeleverd inclusief RRSIG-records. Azure DNS kan de sleutelgeneratie, opslag en automatische resigning overnemen, maar organisaties blijven verantwoordelijk voor het herpubliceren van DS-records, het testen met externe validators zoals de SIDN DNSSEC-check en het documenteren van het bewijs in ENSIA-dossiers.
Sleutelbeheer vraagt dezelfde discipline als PKI. ZSK’s roteren bijvoorbeeld elk kwartaal en worden automatisch vervangen via Azure Key Vault of een HSM terwijl KSK’s jaarlijks in een begeleid change window omwisselen. Rollovers moeten dubbel worden gedocumenteerd: eerst wordt de nieuwe sleutel toegevoegd in de zone en pas als alle resolvers deze zien, wordt de oude verwijderd. Incidentrespons omvat bovendien noodscenario’s waarin een gecompromitteerde sleutel direct moet worden ingetrokken en DS-records per spoedchange bij de registrar worden bijgewerkt. Elke stap levert logbestanden en goedkeuringen die nodig zijn voor BIO-controle-objectief BIV.05.
Integratie met change- en operationsprocessen voorkomt dat DNSSEC een black box blijft. Infra-teams koppelen hun GitHub- of Azure DevOps-pipelines aan de DNS-configuraties zodat iedere wijziging aan records, TTL’s of sleutelmaterialen automatisch een change-ID, testresultaten en rollback-instructies meekrijgt. Monitoring in Microsoft Sentinel of Splunk controleert verlopen handtekeningen, ontbrekende DS-records en validatiefouten van publieke resolvers. Eventuele afwijkingen genereren zowel een incidentticket als een voorgedefinieerde runbookactie, waardoor drift snel zichtbaar wordt.
DNS-over-HTTPS vult DNSSEC aan door de vertrouwelijkheid van queries te beschermen. Met DoH reizen resoluties via TLS 1.3 binnen een HTTP/2- of HTTP/3-tunnel, zodat netwerkafluisteraars geen inzicht meer hebben in welke diensten een ambtenaar raadpleegt. Windows 11, Microsoft Edge en Intune ondersteunen policies waarmee alleen goedgekeurde DoH-resolvers worden gebruikt. Overheden kiezen bij voorkeur een eigen resolver in Azure of bij een vertrouwde Nederlandse leverancier zodat filtering, logging en jurisdictiecontrole behouden blijven. Firewalls blokkeren verkeer naar publieke DoH-diensten om shadow-IT te voorkomen en splitsen DoH-verkeer op in een tenant die ook interne records kan leveren.
Door DNSSEC en DoH samen te implementeren ontstaat een keten van authenticatie én vertrouwelijkheid. Validatie voorkomt dat vervalste antwoorden een gebruiker bereiken, terwijl DoH voorkomt dat een aanvaller de query onderweg manipuleert of analyseert. Het resultaat is een aantoonbaar veilige resolutiearchitectuur waarin elke stap in logboeken, monitoringdashboards en compliance-rapportages wordt vastgelegd en waarmee organisaties richting toezichthouders kunnen aantonen dat DNS niet langer een blinde vlek is.
Protective DNS en detectie: gefilterde resolutie
Protective DNS vormt een extra verdediging bovenop endpointbeveiliging doordat malafide domeinen nooit worden vertaald naar IP-adressen. Diensten zoals de NCSC Protective DNS pilot, Quad9, Cloudflare for Government of door Microsoft beheerde resolvers combineren threat intelligence, machine learning en categorisering. Ze blokkeren phishingcampagnes, command-and-control-kanalen en domeinen die door Domain Generation Algorithms worden aangemaakt voordat gebruikers of workloads überhaupt een verbinding opzetten. Vooral voor BYOD, gastnetwerken en virtuele bureaus is dit een essentieel vangnet omdat daar geen volledige EDR-clients draaien.
Implementatie begint bij de infrastructuurlaag. DHCP-servers, Azure Virtual Network-profielen, Always On VPN-configuraties en Intune-profielen verwijzen standaard naar de beschermende resolver. Voor thuiswerkers en leveranciers legt het SOC vast dat DNS-verkeer altijd door een beveiligde tunnel richting het overheidsnetwerk loopt, zodat dezelfde filtering geldt als op kantoor. Shared service centers koppelen interne Windows DNS-servers als forwarder aan de beschermde dienst en certificeren iedere wijziging in het changeproces. Het resultaat is een uniforme policy, ongeacht of een ambtenaar via Wi-Fi, 4G of een OT-netwerk werkt.
Beleidstuning is cruciaal om beveiliging en bedrijfsvoering in balans te houden. Securityteams definiëren categorieën zoals malware, botnet, adult content of generatieve AI en koppelen ze aan beleidsbesluiten van CISO, FG en ondernemingsraad. Een duidelijke procedure bepaalt hoe een foutpositief tijdelijk wordt toegestaan, welke onderbouwing nodig is en hoe de uitzondering na een review weer wordt ingetrokken. Reportingdashboards geven inzicht in welke diensten regelmatig geblokt worden, welke ketenpartners verdachte aanvragen genereren en welke projecten extra voorlichting nodig hebben.
DNS-firewalls en anomaly detection breiden dit uit met gedragsanalyses. Azure Firewall Premium, Infoblox BloxOne of gespecialiseerde appliances inspecteren DNS-berichten op tunneling, te lange labels of abnormale frequenties. Ze vergelijken querypatronen met baselines van kritieke processen zoals DigiD-verificaties of belastingaangiftes en herkennen zo data-exfiltratie. Rate limiting en query signing voorkomen dat eigen infrastructuur wordt misbruikt in amplificatieaanvallen. Detecties worden rechtstreeks doorgestuurd naar Microsoft Sentinel waar playbooks automatisch een apparaat isoleren, een gebruiker uitschakelen of een incident naar het CSIRT sturen.
Logging en telemetrie vormen het forensische geheugen. Alle query’s, antwoorden en foutcodes worden centraal opgeslagen in Sentinel, Splunk of Elastic, inclusief bron-IP, device-ID en identiteitscontext vanuit Entra ID. Threat hunters kunnen zo terugzoeken welke medewerker verdachte domeinen heeft aangeroepen, of een campagne al langer actief is en of blokkades daadwerkelijk hebben voorkomen dat malware een C2 bereikte. Dashboards koppelen DNS-signalen aan andere indicatoren zoals Defender for Endpoint-alerts of e-maildetecties, waardoor een compleet beeld van de kill chain ontstaat.
Governance maakt de oplossing auditproof. AVG-artikel 5 vereist transparantie over welke persoonsgegevens worden gelogd, dus privacy officers beschrijven bewaartermijnen, pseudonimisering en toegangsrechten in het verwerkingsregister. De BIO en NIS2 vragen daarnaast om KPI’s zoals het percentage verkeer dat via protective DNS loopt, het aantal geblokkeerde pogingen en de gemiddelde oplostijd van uitzonderingsaanvragen. Door deze cijfers maandelijks te bespreken in het securityboard ontstaat continue verbetering en kan het bestuur aantonen dat DNS als kritieke dienst onder controle is.
Incidentrespons-teams gebruiken protective DNS-signalen ook als startpunt voor tabletop-oefeningen. Wanneer een detectie aangeeft dat bijvoorbeeld een verkiezingsapplicatie naar onbekende domeinen belt, koppelen zij het incident direct aan runbooks voor isolatie, communicatie met het NCSC en herstel van vertrouwen richting bestuurders. Door deze scenario’s vooraf te trainen en de lessons learned weer in policies, scripts en awarenessprogramma’s te verwerken, blijft de filtering niet beperkt tot tooling maar wordt het een integraal onderdeel van de crisisorganisatie.
DNS-beveiliging wordt vaak gezien als infrastructuurdetail, maar in werkelijkheid bepaalt het of burgers veilig bij digitale diensten komen en of aanvallers zich ongestoord in de keten kunnen nestelen. Door DNSSEC-validatie als eerste verdedigingslinie neer te zetten, autoritatieve zones verantwoord te ondertekenen, DoH gefaseerd uit te rollen en protective DNS plus firewalling te combineren met intelligente logging, ontstaat een keten die zowel beschikbaarheid als vertrouwelijkheid borgt. Het levert bovendien direct bewijs op voor ENSIA, NIS2 en de Nederlandse Baseline voor Veilige Cloud.
Bestuurders die DNS-beveiliging prioriteren, reserveren budget voor beheerde resolvers, key-rotaties, monitoring en SIEM-opslag, stellen duidelijke beleidsregels op over privacy en logging en koppelen KPI’s aan de strategische doelstellingen rond digitale weerbaarheid. Zo verandert DNS van een kwetsbaar fundament in een gecontroleerde dienst die innovatie en publieke dienstverlening versnelt in plaats van remt.