NIS2 en DNS — Wat gereguleerde EU-operatoren moeten weten
Hoe de NIS2-richtlijn (EU 2022/2555) van toepassing is op DNS — verplichtingen van de leverancier, risicomanagementmaatregelen, incidentmelding en wat te eisen van uw DNS-leverancier.
TL;DR
De NIS2-richtlijn (EU 2022/2555) classificeert 'aanbieders van DNS-diensten' als essentiële entiteiten — zij moeten risicomanagementmaatregelen implementeren (Art. 21), significante incidenten binnen 24/72 uur melden (Art. 23), en niet-naleving kan leiden tot boetes tot 10 miljoen euro of 2% van de wereldwijde omzet. Operatoren die afhankelijk zijn van DNS moeten de NIS2-paraatheid van hun leverancier verifiëren en hun eigen DNS-gerelateerde processen (delegatie, DNSSEC, change management) afstemmen op de richtlijn.
What you'll learn
- Begrijpen welke entiteiten binnen het toepassingsgebied van NIS2 vallen en waar DNS-leveranciers passen
- De risicomanagementmaatregelen uit Artikel 21 identificeren die van toepassing zijn op DNS-operaties
- De NIS2-meldingstermijnen (24u / 72u / 1 maand) afbeelden op DNS-specifieke incidenten
- Een afnemerskant-checklist opstellen om de NIS2-conformiteit van een DNS-leverancier te beoordelen
De NIS2-richtlijn (Richtlijn (EU) 2022/2555) is de vlaggenschipregelgeving van de EU op het gebied van cybersecurity. Hij breidt de oorspronkelijke NIS-richtlijn uit en verstrengt deze, verhoogt de basiseisen voor cybersecurity in heel de Unie en brengt tienduizenden nieuwe entiteiten binnen het toepassingsgebied. Voor iedereen die DNS in of voor de EU exploiteert, is NIS2 niet langer optioneel — het is de wettelijke ondergrens.
Deze gids behandelt wat NIS2 specifiek betekent voor DNS: welke entiteiten binnen het toepassingsgebied vallen, hoe de risicomanagementmaatregelen uit Artikel 21 eruitzien in DNS-operaties, de meldingstermijnen voor incidenten waaraan een DNS-leverancier moet voldoen, en een afnemerskant-checklist om te beoordelen of uw DNS-leverancier NIS2-klaar is.
Wat NIS2 is en waarom het bestaat
NIS2 is in december 2022 aangenomen en lidstaten hadden tot 17 oktober 2024 om het in nationaal recht om te zetten. Het vervangt de NIS-richtlijn van 2016 (NIS1), die breed bekritiseerd werd vanwege inconsistente handhaving, beperkte sectorale dekking en zwakke toezichtsbevoegdheden.
Het verklaarde doel van de richtlijn is het vaststellen van een hoog gemeenschappelijk niveau van cybersecurity in heel de Unie. Dit gebeurt door:
- De lijst met sectoren binnen het toepassingsgebied uit te breiden, inclusief digitale infrastructuur, openbaar bestuur, voedselproductie en afvalbeheer.
- De drempelwaarden te verlagen — de meeste middelgrote organisaties (>=50 werknemers of >=10 mln EUR omzet) vallen nu binnen het toepassingsgebied.
- Twee toezichtsniveaus voor te schrijven: essentiële entiteiten (proactief toezicht, hoogste verplichtingen) en belangrijke entiteiten (reactief toezicht, iets lichtere eisen).
- De boetes te verhogen: tot 10 mln EUR of 2% van de wereldwijde jaaromzet voor essentiële entiteiten, 7 mln EUR of 1,4% voor belangrijke entiteiten.
- Persoonlijke aansprakelijkheid van bestuursorganen die cybersecurityverplichtingen niet nakomen, te introduceren.
- De meldingstermijnen en -inhoud voor incidenten in de EU te harmoniseren.
Als uw organisatie binnen het toepassingsgebied valt, is NIS2 geen zacht nalevingsregime. Nationale regelgevers (BSI in Duitsland, ANSSI in Frankrijk, NCSC-NL in Nederland enz.) hebben nu expliciete bevoegdheden om te inspecteren, auditen en boetes op te leggen.
Waar DNS in NIS2 zit
Bijlage I van NIS2 somt de sectoren op met hoge kritikaliteit. Onder de noemer "digitale infrastructuur" worden de volgende expliciet genoemd als essentiële entiteiten:
- Beheerders van internetuitwisselingspunten
- Aanbieders van DNS-diensten (met uitzondering van beheerders van rootnameservers)
- TLD-naamregisters
- Aanbieders van cloud-computingdiensten
- Aanbieders van datacenterdiensten
- Aanbieders van content delivery networks
- Vertrouwensdienstverleners (eIDAS)
- Aanbieders van openbare elektronische communicatienetwerken
- Aanbieders van openbare elektronische communicatiediensten
De term "aanbieders van DNS-diensten" is breed. Hij omvat autoritatieve DNS-leveranciers (entiteiten die queries over een zone beantwoorden — DNScale, Cloudflare DNS, Route 53, ClouDNS, DNS Made Easy, Dyn enz.), beheerders van publieke recursieve resolvers (Quad9, OpenDNS, Cloudflare 1.1.1.1, Google Public DNS) en aanbieders van enterprise / managed-DNS-diensten. Interne / privé-DNS dat alleen door één organisatie wordt gebruikt valt over het algemeen niet als dienst binnen het toepassingsgebied, hoewel het wel binnen het toepassingsgebied kan vallen als onderdeel van de bredere infrastructuur van die organisatie.
Lidstaten kunnen de lijst uitbreiden — het Duitse NIS2UmsuCG-concept behandelt bijvoorbeeld sommige hostingaanbieders ruimer dan het EU-minimum.
Artikel 21 — De risicomanagementmaatregelen
Artikel 21 is het operationele hart van NIS2. Het verplicht essentiële en belangrijke entiteiten om "passende en evenredige technische, operationele en organisatorische maatregelen" te nemen om cybersecurityrisico's te beheren. De richtlijn somt 10 maatregelcategorieën op:
- Risicoanalyse en informatiesysteembeveiligingsbeleid
- Incidentafhandeling
- Bedrijfscontinuïteit, inclusief back-upbeheer en herstel
- Beveiliging van de toeleveringsketen, inclusief beveiliging van relaties met directe leveranciers en dienstverleners
- Beveiliging in verwerving, ontwikkeling en onderhoud van netwerk- en informatiesystemen, inclusief afhandeling en bekendmaking van kwetsbaarheden
- Procedures om de doeltreffendheid te beoordelen van cybersecurity-risicomanagementmaatregelen
- Basis cyberhygiënepraktijken en cybersecuritytraining
- Beleid en procedures betreffende het gebruik van cryptografie en, waar passend, encryptie
- Beveiliging van human resources, beleid voor toegangscontrole en assetbeheer
- Gebruik van multi-factor authenticatie of continue authenticatieoplossingen, beveiligde stem-/video-/tekstcommunicatie en beveiligde noodcommunicatiesystemen
Voor DNS specifiek vertaalt dit zich in concrete operationele eisen:
1. Incidentafhandeling voor DNS-uitval en compromittering
Een DNS-leverancier moet schriftelijke procedures hebben voor het reageren op:
- Autoritatieve uitval in een PoP, regio of wereldwijd
- DDoS-aanvallen tegen het anycast-netwerk
- Compromittering van zonegegevens (ongeautoriseerde wijziging van klantrecords)
- Compromittering van DNSSEC-sleutels (blootstelling van privésleutel KSK of ZSK)
- Compromittering van operatoraccounts die kan leiden tot recordwijzigingen
Procedures moeten detectie, inperking, eradicatie, herstel en post-incidentanalyse omvatten. Ze moeten getest worden. Klanten mogen een beveiligingscontact, een incident-response runbook en een gepubliceerde RTO/RPO voor DNS-dienst verwachten.
2. Cryptografie waar passend
DNSSEC is de meest direct relevante cryptografische controle voor DNS. Onder Artikel 21(2)(h) loopt een DNS-leverancier die helemaal geen DNSSEC aanbiedt het risico als niet-conform beoordeeld te worden voor klanten met hoge kritikaliteit. DNSSEC-functies verwacht in 2026:
- Algoritme-ondersteuning: ECDSA P-256 (algoritme 13) of Ed25519 (algoritme 15) — RSA-SHA256 (algoritme 8) is acceptabel maar wordt als legacy beschouwd.
- Geautomatiseerde sleutelrotatie (KSK en ZSK) zonder downtime voor de klant.
- Veilige sleutelopslag — HSM-ondersteund of gelijkwaardig.
- Publieke DS-rapportage via API voor registrar-automatisering.
Voor data in transit tussen operator-interfaces en klanten is TLS 1.2+ met moderne cipher suites het minimum.
3. Toeleveringsketenbeveiliging — Artikel 21(2)(d)
Deze bepaling is waar NIS2 ook klanten van DNS-leveranciers raakt. Artikel 21(2)(d) verplicht elke entiteit binnen het toepassingsgebied om de beveiliging van relaties met directe leveranciers te beheren. Als uw DNS-leverancier een beveiligingsincident heeft dat u raakt, verwachten regelgevers dat u vooraf due diligence heeft gedaan.
In de praktijk betekent dit:
- Documenteer de leveranciers in uw DNS-toeleveringsketen (registrar, primaire DNS-host, secundaire DNS-host, beheerde recursieve resolver indien van toepassing).
- Verkrijg bewijs van hun beveiligingshouding (certificeringen, auditrapporten, publiek beveiligingsbeleid).
- Vestig contractuele SLA's voor incidentmelding en herstel.
- Heroverweeg op een gedocumenteerde cadans (minimaal jaarlijks).
4. Multi-factor authenticatie
Artikel 21(2)(j) vereist MFA voor beheersinterfaces. Voor DNS betekent dat:
- MFA op het klantdashboard van de DNS-leverancier.
- MFA bij de registrar waar NS-records worden beheerd (delegatiebeveiliging).
- API-sleutelbeheer met beperkte rechten en rotatiebeleid.
- Geen langdurige gedeelde inloggegevens; serviceaccounts moeten controleerbaar zijn.
5. Bedrijfscontinuïteit en back-up
DNS-specifieke bedrijfscontinuïteit:
- Multi-region anycast zodat een enkele regionale storing een zone niet offline brengt.
- Multi-provider DNS voor zones van het hoogste niveau — zie
/learning/multi-provider-dns-deployment. - Back-ups van zonegegevens die snel hersteld kunnen worden bij een andere leverancier.
- Geteste hersteldures met gedocumenteerde RTO/RPO.
Artikel 23 — Meldingstermijnen voor incidenten
Artikel 23 stelt de meldingstermijn vast waaraan DNS-leveranciers moeten voldoen. Een "significant incident" is een incident dat:
- Een substantiële operationele verstoring van diensten of een financieel verlies heeft veroorzaakt of kan veroorzaken
- Andere natuurlijke of rechtspersonen heeft beïnvloed of kan beïnvloeden door aanzienlijke materiële of immateriële schade te veroorzaken
Voor DNS omvat dit langdurige autoritatieve uitval, DNSSEC-validatiefouten veroorzaakt door fouten van de leverancier, ongeautoriseerde wijzigingen aan zonegegevens van de klant, of compromittering van DNSSEC-privésleutels.
Meldingscadans:
| Fase | Termijn | Vereiste inhoud |
|---|---|---|
| Vroege waarschuwing | Binnen 24 uur na kennisname | Of het incident vermoedelijk is veroorzaakt door onrechtmatige of kwaadwillige handelingen en of het grensoverschrijdende impact heeft |
| Incidentmelding | Binnen 72 uur | Een update van de vroege waarschuwing met initiële beoordeling, inclusief ernst, impact en compromitteringsindicatoren |
| Tussentijdse rapportage | Op verzoek | Relevante statusupdates |
| Eindrapport | Binnen 1 maand na incidentmelding | Gedetailleerde beschrijving, soort dreiging, toegepaste en lopende mitigaties, grensoverschrijdende impact |
Deze termijnen zijn van toepassing op de DNS-leverancier als de entiteit binnen het toepassingsgebied. Klanten kunnen afzonderlijke meldingsverplichtingen hebben jegens hun eigen regelgevers als het DNS-incident downstream-impact veroorzaakt in hun eigen sector.
De 24-uurs vroege waarschuwing is kort. Een DNS-leverancier moet monitoring, paging en een aangewezen melder klaar hebben om bij het nationale CSIRT of bevoegde autoriteit te melden. Dit is geen kwartaaloefening.
Wat dit betekent voor DNS-klanten — een praktische checklist
Als uw organisatie binnen het toepassingsgebied van NIS2 valt (of leverancier is van een gedekte entiteit), hier een praktische checklist om uw DNS-leverancier te beoordelen:
Leveranciersonderzoek
- Leverancier wordt genoemd / is bereid schriftelijk te bevestigen of hij binnen het toepassingsgebied valt als aanbieder van DNS-diensten onder NIS2.
- Primaire jurisdictie van de leverancier en bevoegde autoriteit die toezicht houdt.
- Publieke beveiligingshouding: security.txt, kwetsbaarhedenmeldingsbeleid en gepubliceerde status voor versleutelde beveiligingsmeldingen.
- Publieke post-incidentrapporten van eerdere significante incidenten (indien aanwezig).
- Gedocumenteerde incident-response procedure en meldings-SLA in uw contract.
Technische controles
- DNSSEC-ondersteuning met moderne algoritmen (ECDSA P-256 of Ed25519).
- HSM-ondersteunde of gelijkwaardige veilige sleutelopslag.
- MFA op het klantdashboard.
- Granulaire API-sleutels (zonebeperkt, tijdgebonden, roteerbaar) — zie
/learning/multi-user-accounts. - Multi-region anycast — zie
/learning/anycast-dns-network. - Auditlog van alle dashboard- en API-acties, bewaard volgens uw bewaarbeleid.
Veerkracht
- Gedocumenteerde RTO/RPO voor de autoritatieve dienst.
- Mechanisme om zonegegevens op aanvraag te exporteren voor portabiliteit.
- Multi-provider-DNS-paraatheid (Terraform / DNSControl-ondersteuning) — zie
/learning/multi-provider-dns-deployment.
EU-specifieke overwegingen
- Leverancier exploiteert EU-jurisdictionele infrastructuur als uw sector data-residentie vereist.
- DNS-querytraffic kan worden beperkt tot EU-PoP's (bv. de EU-nameserverset van DNScale — zie
/learning/dns-delegation-by-region). - Contracten onder EU-recht en EU-geschillenbeslechting.
Waar DNScale staat
DNScale opereert als EU-jurisdictionele DNS-leverancier met een NIS2-bewust operatiemodel:
- EU-operaties: infrastructuur en operaties binnen de EU; querytraffic kan worden beperkt tot EU-PoP's via de EU-nameserverset.
- DNSSEC: ECDSA P-256 standaard; geautomatiseerde sleutelrotatie; HSM-ondersteunde sleutelopslag.
- MFA + beperkte API-sleutels: dashboard-MFA, zonebeperkte sleutels, volledig auditlog — zie
/learning/multi-factor-authentication-guideen de DNScale-API-sleuteldocumentatie. - Multi-region anycast via
/learning/anycast-dns-networken/learning/global-dns-resolution-balancingvoor veerkracht. - Multi-provider-paraatheid: Terraform- en DNSControl-providers zijn vandaag beschikbaar — zie
/learning/terraform-provider-guideen/learning/dnscontrol-guide. - Publieke beveiligingsartefacten: security.txt en kwetsbaarhedenmeldingsbeleid op standaardlocaties; post-incidentrapporten gepubliceerd waar van toepassing.
Voor sectoren waar de NIS2-handhaving het actiefst is — financieel, energie, openbaar bestuur, gezondheidszorg — vermindert het verplaatsen van de DNS-levering naar een EU-jurisdictionele leverancier met NIS2-aligned controles zowel het regulatoire risico als de documentatielast voor de toeleveringsketen onder Artikel 21(2)(d).
Referenties
- Richtlijn (EU) 2022/2555 — de NIS2-richtlijn
- ENISA-richtsnoeren over NIS2-implementatie — praktische bronnen voor gedekte entiteiten
- BSI NIS2UmsuCG-concept — Duitse omzetting
- ANSSI-gids NIS 2 — Franse omzetting
- RFC 8945 — TSIG (authenticatie van zone-overdrachten, relevant voor cryptografiemaatregelen)
- RFC 4034/4035 — DNSSEC-kernprotocol
- RFC 8901 — Multi-Signer DNSSEC (relevant voor multi-provider deployments)
Gerelateerde lectuur
- DNS-beveiliging best practices — operationele hardening
- DNSSEC-sleutelbeheer — cryptografie in de praktijk
- Multi-provider DNS-deployment — veerkracht in de toeleveringsketen
- DNScale vs Cloudflare — vergelijking onder EU-jurisdictie
- Beste EU-DNS-leveranciers — beoordelingsraamwerk
- GDPR-conforme DNS-leveranciers — aangrenzend regelgevend kader
Frequently asked questions
- Is NIS2 van toepassing op mijn organisatie als wij alleen DNS gebruiken zonder het te leveren?
- Mogelijk wel. NIS2 dekt veel sectoren (energie, vervoer, bankwezen, gezondheid, water, digitale infrastructuur, openbaar bestuur, productie van kritieke producten, voedsel, post enz.) en is van toepassing op middelgrote en grote entiteiten (>=50 werknemers of >=10 mln EUR omzet) in deze sectoren. Als u binnen het toepassingsgebied valt, strekken uw verplichtingen voor toeleveringsketenbeveiliging onder Artikel 21(2)(d) zich uit tot uw DNS-leverancier — u moet verifiëren dat deze gelijkwaardige standaarden hanteert.
- Worden DNS-leveranciers expliciet genoemd in NIS2?
- Ja. Bijlage I noemt 'aanbieders van DNS-diensten' (samen met TLD-naamregisters, beheerders van internetuitwisselingspunten en andere beheerders van digitale infrastructuur) als essentiële entiteiten. Dit plaatst DNS-leveranciers in het strengste niveau — proactief toezicht, verplichte incidentmelding en het hoogste boete-plafond.
- Wat moet een DNS-leverancier melden onder NIS2?
- Een 'significant incident' — gedefinieerd als een incident dat operationele verstoring, financieel verlies of impact op andere entiteiten veroorzaakt. Voor DNS omvat dit: langdurige autoritatieve uitval in een regio, DDoS die een klant gedurende langere tijd offline brengt, DNSSEC-validatiefouten veroorzaakt door fouten van de leverancier, ongeautoriseerde toegang tot zonegegevens, of compromittering van DNSSEC-privésleutels. Tijdlijn van Artikel 23: vroege waarschuwing binnen 24 uur, volledige melding binnen 72 uur, eindrapport binnen 1 maand.
- Waar moet ik op letten bij het kiezen van een DNS-leverancier voor NIS2-naleving?
- Gedocumenteerde Artikel 21-maatregelen (incidentafhandeling, cryptografie, controles toeleveringsketen), publieke beveiligingshouding (security.txt, kwetsbaarhedenmelding, post-incidentrapporten), DNSSEC-ondersteuning, multi-region anycast voor veerkracht, bewijs van een incidentmeldingsworkflow en data-residentieopties voor DNS-querytraffic als uw sector dit vereist. EU-jurisdictie is belangrijk: NIS2-toezicht is per lidstaat, en een niet-EU-leverancier kan complexiteit toevoegen.
- Hoe verschilt NIS2 van de oorspronkelijke NIS-richtlijn?
- NIS1 (2016) dekte minder sectoren en werd zwak gehandhaafd — veel lidstaten implementeerden hem minimaal. NIS2 (2022, omzettingsdeadline oktober 2024) breidde het toepassingsgebied aanzienlijk uit (meer sectoren, lagere drempelwaarden), maakte toezicht verplicht, verhoogde boetes (tot 10 mln EUR of 2% van de wereldwijde omzet voor essentiële entiteiten) en introduceerde persoonlijke aansprakelijkheid voor het management. Het is van toepassing in alle 27 EU-lidstaten met geharmoniseerde basisregels.
- Mijn leverancier is buiten de EU — ben ik automatisch niet-conform?
- Niet automatisch. NIS2 verbiedt geen buitenlandse leveranciers, maar Artikel 21(2)(d) vereist dat u toeleveringsketenrisico beheert, wat betekent dat u moet aantonen dat uw DNS-leverancier, waar deze ook is gevestigd, gelijkwaardige standaarden hanteert. EU-gevestigde leveranciers vereenvoudigen het bewijs (één jurisdictie, GDPR-aligned, NIS2 direct afdwingbaar). Niet-EU-leveranciers vereisen aanvullende contractuele en technische due diligence.
Related guides
Wat is DNSSEC? Een eenvoudige gids voor DNS-beveiliging
DNSSEC uitgelegd vanaf de basis — wat het is, waarom het bestaat, hoe het op hoog niveau werkt, en wanneer u het zou moeten activeren voor uw domein.
Hoe DNSSEC werkt — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC uitgelegd
Een doorloop van de DNSSEC-vertrouwensketen: hoe KSK- en ZSK-handtekeningsleutels, DS-records, DNSKEY-records, RRSIG-handtekeningen en NSEC/NSEC3 samenwerken om DNS-antwoorden te authentiseren.
DNSSEC-installatiehandleiding voor DNScale — Stap voor stap
Activeer DNSSEC op een DNScale-zone in minder dan 10 minuten — sleutels genereren, DS kopiëren naar uw registrar, verifiëren, en de meest voorkomende rotatiefouten vermijden.
Ready to manage your DNS with confidence?
DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.
Start free