NIS2 and DNS — What Regulated EU Operators Need to Know

The NIS2 Directive (Directive (EU) 2022/2555) is the EU's flagship cybersecurity regulation. It expands and tightens the original NIS Directive, raises baseline cybersecurity requirements across the bloc, and brings many new entities into scope. For organisations running DNS in or for the EU, NIS2 is an important legal baseline where the organisation is in scope.

This guide is current as of 2026-06-06 and is for operational planning, not legal advice. NIS2 is an EU directive implemented through national law, so scope, supervisory authority, deadlines, and enforcement details can vary by member state.

This guide covers what NIS2 means for DNS specifically: which entities are in scope, what the Article 21 risk-management measures look like in DNS operations, the incident-reporting timelines that DNS providers must meet, and a buyer-side checklist for evaluating how your DNS supplier supports NIS2 due diligence.

What NIS2 Is and Why It Exists

NIS2 was adopted in December 2022 and member states had until 17 October 2024 to transpose it into national law. It replaces the 2016 NIS Directive (NIS1), which was widely criticised for inconsistent enforcement, narrow sectoral coverage, and weak supervisory powers.

The directive's stated goal is to establish a high common level of cybersecurity across the Union. It does this by:

1. Expanding the list of sectors in scope, including digital infrastructure, public administration, food production, and waste management.
2. Lowering size thresholds — most medium-sized organisations (≥50 employees or ≥€10M turnover) are now in scope.
3. Distinguishing essential entities and important entities, with different supervisory measures and obligations.
4. Setting directive-level administrative fine ceilings, subject to national implementation.
5. Introducing personal liability for management bodies that fail to meet cybersecurity obligations.
6. Harmonising incident reporting timelines and content across the EU.

If your organisation is in scope, NIS2 is not a soft compliance regime. National regulators (BSI in Germany, ANSSI in France, NCSC-NL in the Netherlands, etc.) have powers under national implementing law to inspect, audit, and impose measures or fines.

Where DNS Sits in NIS2

Annex I of NIS2 lists the sectors of high criticality. Under the heading "Digital infrastructure," the following are named explicitly as essential entities:

• Internet exchange point providers
• DNS service providers (excluding root nameserver operators)
• TLD name registries
• Cloud computing service providers
• Data centre service providers
• Content delivery network providers
• Trust service providers (eIDAS)
• Providers of public electronic communications networks
• Providers of publicly available electronic communications services

The phrase "DNS service providers" is broad. It captures authoritative DNS providers (the entities that answer queries about a zone — DNScale, Cloudflare DNS, Route 53, ClouDNS, DNS Made Easy, Dyn, etc.), recursive resolver operators serving the public (Quad9, OpenDNS, Cloudflare 1.1.1.1, Google Public DNS), and enterprise/managed-DNS service providers. Internal/private DNS used only by one organisation is generally not in scope as a service, although it may be in scope as part of that organisation's broader infrastructure.

Member states may extend the list — Germany's NIS2UmsuCG draft, for example, treats some hosting providers more broadly than the EU directive minimum.

Article 21 — The Cybersecurity Risk-Management Measures

Article 21 is the operational heart of NIS2. It requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. The directive lists 10 specific measure categories:

1. Risk analysis and information system security policies
2. Incident handling
3. Business continuity, including backup management and disaster recovery
4. Supply-chain security, including the security of relationships with direct suppliers and service providers
5. Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure
6. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
7. Basic cyber hygiene practices and cybersecurity training
8. Policies and procedures regarding the use of cryptography and, where appropriate, encryption
9. Human resources security, access control policies and asset management
10. The use of multi-factor authentication or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems

For DNS specifically, this translates into concrete operational requirements:

1. Incident Handling for DNS Outages and Compromise

A DNS provider must have written procedures for responding to:

• Authoritative outages in a PoP, region, or globally
• DDoS attacks against the anycast network
• Zone-data compromise (unauthorised modification of customer records)
• DNSSEC key compromise (KSK or ZSK private-key exposure)
• Operator account compromise that could lead to record changes

Procedures must include detection, containment, eradication, recovery, and post-incident analysis. They must be tested. Customers should expect a security contact, an incident-response runbook, and a published RTO/RPO for DNS service.

2. Cryptography Where Appropriate

DNSSEC is the most directly relevant cryptographic control for DNS. Under Article 21(2)(h), a DNS provider that does not offer DNSSEC at all may be harder to justify for high-criticality customers that need cryptographic DNS integrity controls. DNSSEC features commonly expected in 2026:

• Algorithm support: ECDSA P-256 (algorithm 13) or Ed25519 (algorithm 15) — RSA-SHA256 (algorithm 8) is acceptable but considered legacy.
• Automated key rollover (KSK and ZSK) without customer downtime.
• Secure key storage — HSM-backed or equivalent.
• Public DS reporting via API for registrar automation.

For data in transit between operator interfaces and customers, TLS 1.2+ with modern cipher suites is the baseline.

3. Supply-Chain Security — Article 21(2)(d)

This provision is where NIS2 reaches customers of DNS providers. Article 21(2)(d) requires every in-scope entity to manage the security of relationships with direct suppliers. If your DNS provider has a security incident that affects you, regulators expect you to have done due diligence in advance.

Practically, this means:

• Document the providers in your DNS supply chain (registrar, primary DNS host, secondary DNS host, recursive resolver if managed).
• Obtain evidence of their security posture (certifications, audit reports, public security policy).
• Establish contractual SLAs for incident notification and recovery.
• Reassess on a documented cadence (annually at minimum).

4. Multi-Factor Authentication

Article 21(2)(j) lists multi-factor authentication or continuous authentication solutions among the measures to use where appropriate. For DNS management surfaces, that usually means:

• MFA on the DNS provider's customer dashboard.
• MFA on the registrar where NS records are managed (delegation security).
• API key management with scoped permissions and rotation policy.
• No long-lived shared credentials; service accounts must be auditable.

5. Business Continuity and Backup

DNS-specific business continuity:

• Multi-region anycast so a single regional failure does not take a zone offline.
• Multi-provider DNS for the highest-tier zones — see /learning/multi-provider-dns-deployment.
• Zone-data backups that can be restored to a different provider quickly.
• Tested recovery procedures with documented RTO/RPO.

Article 23 — Incident Reporting Timelines

Article 23 sets the incident-reporting timeline that DNS providers must meet. A "significant incident" is one that has:

• Caused or is capable of causing substantial operational disruption of services or financial loss
• Affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage

For DNS, this includes prolonged authoritative outages, DNSSEC validation failures caused by provider error, unauthorised changes to customer zone data, or compromise of DNSSEC private keys.

The reporting cadence:

These timelines apply to the DNS provider as the in-scope entity. Customers may have separate reporting obligations to their own regulators if the DNS incident causes them downstream impact in their own sector.

The 24-hour early warning is short. A DNS provider must have monitoring, paging, and a designated reporter ready to file with the national CSIRT or competent authority. This is not a quarterly exercise.

What This Means for DNS Customers — A Practical Checklist

If your organisation is in scope for NIS2 (or is a supplier to an in-scope entity), here is a practical checklist for evaluating your DNS provider:

Provider Due Diligence

• Provider is named/willing to confirm in writing whether it is in scope as a DNS service provider under NIS2.
• Provider's primary jurisdiction and the competent authority that supervises it.
• Public security posture: security.txt, vulnerability disclosure policy, and published status for encrypted security reporting.
• Public post-incident reports for previous significant incidents (if any).
• Documented incident-response procedure and notification SLA in your contract.

Technical Controls

• DNSSEC support with modern algorithms (ECDSA P-256 or Ed25519).
• HSM-backed or equivalent secure key storage.
• MFA on the customer dashboard.
• Granular API keys (zone-scoped, time-bound, rotatable) — see /learning/multi-user-accounts.
• Multi-region anycast — see /learning/anycast-dns-network.
• Audit log of all dashboard and API actions, retained per your retention policy.

Resilience

• Documented RTO/RPO for the authoritative service.
• Mechanism to export zone data on demand for portability.
• Multi-provider DNS readiness (Terraform / DNSControl support) — see /learning/multi-provider-dns-deployment.

EU-Specific Considerations

• Provider operates EU-jurisdictional infrastructure if your sector requires data-residency.
• Authoritative DNS serving can be limited to EU/EEA PoPs where required (e.g., DNScale's EU nameserver set — see /learning/dns-delegation-by-region); packet paths still depend on internet routing.
• Contracts use an EU/EEA member-state governing law and dispute forum, or your legal review documents why another jurisdiction is acceptable.

Where DNScale Fits

DNScale operates through DNScale OÜ, an Estonian EU-jurisdiction DNS provider with a NIS2-aware operating model as of 2026-06-06:

• Domicile: DNScale OÜ is registered in Estonia; customer contracts use Estonian law as specified in the Terms of Service.
• EU operations: EU/EEA authoritative serving and operations are available via the EU nameserver set; internet packet paths still depend on third-party routing.
• DNSSEC: ECDSA P-256 by default; automated key rollover; HSM-backed key storage.
• MFA + scoped API keys: dashboard MFA, zone-scoped keys, full audit trail — see /learning/multi-factor-authentication-guide and the DNScale API keys docs.
• Multi-region anycast via /learning/anycast-dns-network and /learning/global-dns-resolution-balancing for resilience.
• Multi-provider readiness: Terraform and DNSControl providers ship today — see /learning/terraform-provider-guide and /learning/dnscontrol-guide.
• Public security artefacts: security.txt and vulnerability disclosure policy at well-known locations; post-incident reports published when applicable.

For sectors where NIS2 supervision is active — financial, energy, public administration, healthcare — moving DNS supply to an EU-jurisdictional provider with NIS2-aligned controls can reduce evidence-gathering and supply-chain documentation burden under Article 21(2)(d). Whether it reduces legal risk depends on your scope, contracts, national law, and regulator expectations.

References

• Directive (EU) 2022/2555 — the NIS2 Directive
• ENISA NIS2 implementation guidance — practical resources for in-scope entities
• Bundestag NIS2 implementation bill — Germany's national transposition
• ANSSI guide NIS 2 — France's national transposition
• RFC 8945 — TSIG (zone-transfer authentication, relevant under cryptography measures)
• RFC 4034/4035 — DNSSEC core protocol
• RFC 8901 — Multi-Signer DNSSEC (relevant for multi-provider deployments)

Related Reading

• DNS Security Best Practices — operational hardening
• DNSSEC Key Management — cryptography in practice
• Multi-Provider DNS Deployment — supply-chain resilience
• DNScale vs Cloudflare — EU jurisdiction comparison
• Best EU DNS Providers — evaluation framework
• GDPR-Compliant DNS Providers — adjacent regulatory framing