DNS Operator and TLD Registry Security Under NIS2: CIR 2024/2690 Requirements for DNSSEC, Zone Transfer Controls, and Resolver Hardening

DNS infrastructure sits at the centre of NIS2’s digital infrastructure scope — and unlike most sectors where the size test (100+ employees or €20 million turnover) determines whether an entity qualifies, DNS service providers and TLD name registries are essential entities by classification alone. A three-person operation running authoritative nameservers for third parties faces the same €10 million penalty ceiling as a national ISP.

Commission Implementing Regulation (EU) 2024/2690 — the CIR that entered into force on 7 November 2024 — translates NIS2’s broad cybersecurity obligations into binding technical requirements. For DNS infrastructure, the operative provision sits in Annex Section 6.7.2(l): entities must “apply best practices for the security of the DNS, and for Internet routing security and routing hygiene.” That single sentence, read against ENISA’s Technical Implementation Guidance and the incident thresholds in CIR Articles 5 and 6, resolves into a specific set of controls.

This guide maps those controls to the correct NIS2 articles, explains how DNS abuse patterns trigger incident reporting obligations, and clarifies where ccTLD registries carry stricter standards than general DNS service providers.

Who Qualifies as a DNS Operator or TLD Registry Under NIS2

NIS2 creates two distinct in-scope categories for DNS infrastructure, each defined precisely at Article 6.

DNS service providers are defined at Article 6(20) as entities providing: (a) publicly available recursive domain name resolution services for internet end-users; or (b) authoritative domain name resolution services for third-party use. ISP recursive resolvers and public resolver operators fall under limb (a). Managed DNS providers and authoritative nameserver hosting services fall under limb (b). Root name servers are explicitly excluded from the definition.

TLD name registries are defined at Article 6(21) as entities delegated a specific top-level domain and responsible for its administration — including domain registration under the TLD and its technical operation. EU-based ccTLD registries (.nl, .pl, .de, .fr, and others) are in scope. Generic TLD operators serving EU users are also included where NIS2 jurisdiction applies.

Both categories appear in Annex I of the Directive as digital infrastructure. This placement carries a critical consequence: the size exemption that limits NIS2 obligations for most sectors to medium and large enterprises does not apply. A DNS operator or TLD registry is an essential entity regardless of headcount or turnover.

Article 20 adds a personal dimension: management bodies of essential entities must approve and oversee the cybersecurity risk-management measures their organisations implement. Where controls under Article 21(2) are absent or inadequate, individual managers can be held personally liable.

Entity type	In scope?	Classification
ISP recursive resolver (public-facing)	Yes	Essential entity
Managed DNS / authoritative nameserver for clients	Yes	Essential entity
ccTLD registry (.de, .nl, .pl, etc.)	Yes	Essential entity
Root name server operator	No	Excluded — Article 6(20)
Internal enterprise DNS (private use only)	No	Not a DNS service provider
Domain registrar (no nameserver operation)	Partial	Article 28 obligations only

Penalties for essential entities under Article 34(2): up to €10 million or 2% of total global annual turnover in the preceding financial year, whichever is higher.

CIR 2024/2690 Section 6.7.2(l): The DNS “Best Practices” Requirement

Commission Implementing Regulation (EU) 2024/2690 entered into force on 7 November 2024. Its Annex consists of 13 sections covering risk management, incident handling, supply chain security, cryptography, access control, and nine other domains. Network security sits in Section 6.7, and the DNS-specific obligation appears at Section 6.7.2(l):

“Apply best practices for the security of the DNS, and for Internet routing security and routing hygiene of traffic originating from and destined to the network.”

The CIR deliberately uses “best practices” rather than enumerating specific controls — a principle-based approach that allows the requirement to evolve alongside the threat landscape. In practice, this means ENISA’s Technical Implementation Guidance (TIG) becomes the reference document for what satisfies an auditor. ENISA maps Section 6.7.2(l) to four implementation pillars:

Pillar	ENISA expectation	Primary standards
DNSSEC signing	All authoritative zones signed; TLD zones signed	RFC 4641, RFC 9364, NIST SP 800-81r3
Zone transfer security	TSIG authentication + ACL restrictions on AXFR/IXFR	RFC 8945 (TSIG), RFC 5936 (AXFR)
Resolver hardening	DNSSEC validation + encrypted DNS (DoT/DoH) + Protective DNS	RFC 7858 (DoT), RFC 8484 (DoH), ENISA PDNS study 2022
Routing hygiene	BGP route origin validation (ROV) and RPKI filtering	RFC 8210, RFC 6811

Section 6.7.2(l) sits within a broader network security framework: entities must document network architecture, apply perimeter access controls, configure firewalls, manage remote access securely, disable unnecessary services, and monitor traffic anomalies. DNS security is an additional layer on top of that baseline — not a substitute for it.

DNSSEC: Signing the Chain of Trust

DNSSEC allows a resolving nameserver to verify that the records it receives are authentic and unmodified. Without it, an attacker who intercepts DNS traffic or compromises a resolver can substitute malicious records — redirecting users to phishing infrastructure without any visible warning. The mechanism relies on a chain of trust: the DNS root zone is signed, each TLD signs its zone with keys whose public component is published at the root, and each authoritative zone signs its records with keys whose public component is published at the TLD.

For ccTLD registries, zone signing is not optional under NIS2’s best-practices expectation. An unsigned TLD breaks the chain of trust for every domain under it. Even if a registrant signs their own domain correctly, DNSSEC validation provides no protection downstream if the ccTLD zone is unsigned. ENISA’s guidance and the DNS security community — RFC 6840 and RFC 9364 — are uniform on this point. This is a Tier 1 expectation: primary sources are unambiguous, and NIS2 auditors for ccTLD registries will treat unsigned zones as a control gap.

Under the NIS2 framework, DNSSEC signing maps to both Article 21(2)(e) (security in network and information systems acquisition, development and maintenance) via CIR Section 6.7.2(l), and Article 21(2)(h) (policies on use of cryptography). Entities should ensure their cryptography policy covers DNS key management specifically.

Key DNSSEC operational requirements (RFC 4641, NIST SP 800-81r3):

• Key separation: Zone Signing Key (ZSK) for record signing; Key Signing Key (KSK) for signing the DNSKEY RRset. The KSK is the trust anchor referenced by the parent zone and should carry a longer lifecycle (typically one year or more) and higher key strength than the ZSK.
• Key rollover: ZSKs should be rotated regularly; NIST SP 800-81r3 and operational best practices recommend a rotation schedule matched to zone size and risk level — every one to three months is the consensus for high-traffic zones. Emergency rollover procedures must be documented and tested annually.
• Algorithm selection: RSA/SHA-256 (Algorithm 8) and ECDSA P-256/SHA-256 (Algorithm 13) are both acceptable. RSA/MD5 (Algorithm 1) and DSA (Algorithm 3) must not be used.
• NSEC vs NSEC3: NSEC3 with opt-out is preferred for TLD zones with large numbers of unsigned delegations; NSEC is adequate for smaller authoritative zones where zone enumeration is not a concern.
• DS record publication: TLD registries must publish DS records at the root zone for all signed delegations and maintain a documented process for coordinating KSK rollovers with IANA.

Zone Transfer Security and Resolver Hardening

Zone transfer controls

A full zone transfer (AXFR) delivers every DNS record in a zone to the requesting server. In a legitimate deployment, this is how secondary nameservers replicate zone data from the primary. Without access controls, any host on the internet can request an AXFR and receive a complete enumeration of an organisation’s DNS records — a reconnaissance windfall for attackers. TSIG (Transaction Signature, RFC 8945) addresses this by requiring shared-secret HMAC authentication on zone transfer requests. A secondary that cannot present a valid TSIG signature is refused. The complementary control is an ACL at the authoritative nameserver restricting AXFR and IXFR requests to explicitly listed secondary nameserver addresses.

Best practice stack for zone transfer security under CIR Section 6.7.2(l):

• Enable TSIG with HMAC-SHA256 or HMAC-SHA512 on all AXFR/IXFR transactions
• Restrict zone transfer ACLs to authorised secondary nameserver IP addresses only
• Prefer IXFR (incremental transfers) over AXFR where both sides support it — smaller data exposure per transfer
• Log all AXFR/IXFR requests and alert on transfers from unexpected source addresses
• Audit TSIG key rotation at least annually as part of the cryptography policy review cycle

Resolver hardening

Recursive resolvers are the component closest to end users and the most common target for DNS-based attacks. ENISA’s Technical Implementation Guidance identifies four resolver hardening controls that satisfy CIR Section 6.7.2(l):

1. DNSSEC validation: Recursive resolvers must validate DNSSEC signatures, not merely forward signed responses. An unvalidating resolver gains no protection from a signed zone. All major resolver software — BIND 9, Unbound, Knot Resolver — enables validation by default in current versions, but operators must verify this has not been disabled through configuration drift.
2. Encrypted DNS: Deploying DNS-over-TLS (DoT, RFC 7858) or DNS-over-HTTPS (DoH, RFC 8484) for stub-to-resolver communication prevents eavesdropping and tampering between end devices and the resolver. DNS-over-QUIC (DoQ, RFC 9250) is an emerging alternative for latency-sensitive deployments.
3. Protective DNS (PDNS): Filtering at the resolver layer to block queries to known-malicious domains — C&C infrastructure, phishing domains, and DNS abuse categories. ENISA’s 2022 Protective DNS study identifies this as a high-impact, low-complexity control for essential entities. Protective DNS also serves as the primary mitigation for fast-flux and DGA patterns discussed below.
4. Recursion restriction: Resolvers must not accept recursive queries from arbitrary external sources. Open recursive resolvers are both a DNS amplification abuse vector and a security liability. Recursion ACLs should limit queries to the entity’s own user population.

For DNS operators managing both authoritative and recursive infrastructure, the access control documentation required under Article 21(2)(i) should address administrative access to DNS management interfaces separately from end-user query access.

DNS Abuse Under NIS2: Fast-Flux, DGA, and the Breach Liability Exposure

DNS infrastructure operators are not passive participants in DNS abuse incidents — they carry legal obligations under NIS2 to detect and respond to abuse patterns that affect the availability, integrity, and confidentiality of their services.

Fast-flux networks rotate DNS A and AAAA records at very short TTLs — often below 60 seconds — across a large pool of compromised hosts acting as proxies. This continuous rotation makes it difficult to block C&C domains by IP address. A recursive resolver that returns fast-flux responses without filtering is actively delivering abuse infrastructure to end users. For authoritative DNS providers whose customers’ domains are being abused to host fast-flux infrastructure, the integrity obligation under Article 21(2)(b) incident handling is triggered the moment the operator becomes aware.

Domain generation algorithms (DGA) are used by malware families to generate pseudo-random domain names algorithmically. Infected devices query these algorithmically generated domains at high volume. The majority return NXDOMAIN, but the query load itself degrades resolver performance. A sustained DGA-generated NXDOMAIN flood can push average response times above the 10-second threshold for more than one hour — the trigger for a significant incident under CIR Article 5 (response time criterion). That transforms an abuse event into a notifiable incident with a 24-hour early warning deadline.

NIS2 and CIR mapping for DNS abuse:

Abuse type	NIS2 / CIR trigger	Consequence
DGA NXDOMAIN flood pushing response time >10s for >1h	CIR Article 5 — response time criterion (criterion 2)	Significant incident — 24h early warning required
DNS zone data poisoning or hijacking	CIR Article 5 — data integrity criterion (criterion 3)	Significant incident unless <1,000 domains and ≤1% of total managed domains affected by misconfiguration
TLD-level outage from volumetric attack	CIR Article 6 — availability criterion (criterion 1)	Significant incident immediately — no 30-minute grace period for TLD registries
Fast-flux C&C resolution (users harmed)	Article 21(2)(b) — incident handling obligation	Must have documented detection and response procedures
Synthetic registrant data enabling abuse domains	Article 28 — verification obligation	Registration verification procedures required

Protective DNS deployment at the resolver layer is the ENISA-recommended primary control: by filtering queries to known DGA-associated and fast-flux domains using threat intelligence feeds, operators reduce both user impact and the probability of crossing the CIR Article 5 availability threshold. Protective DNS also generates the query logs needed to demonstrate detection capability to an auditor.

Significant Incident Reporting: CIR Articles 5 and 6

CIR 2024/2690 sets distinct incident thresholds for DNS service providers and TLD name registries. The distinction is operationally significant: TLD registries face a stricter standard at the availability threshold.

CIR Article 5 — DNS service providers

An incident is significant if any one of the following thresholds is met:

1. A recursive or authoritative DNS service is completely unavailable for more than 30 minutes
2. The average response time of a recursive or authoritative DNS service to requests is more than 10 seconds for a period of more than one hour
3. The integrity, confidentiality, or authenticity of data related to the authoritative DNS service is compromised — unless fewer than 1,000 domain names are affected and those represent no more than 1% of total managed domains, and the cause is a misconfiguration

CIR Article 6 — TLD name registries

An incident is significant if any one of the following thresholds is met:

1. The authoritative DNS service for the TLD is completely unavailable — no minimum duration; any total outage qualifies immediately
2. The average response time to requests is more than 10 seconds for a period of more than one hour
3. The integrity, confidentiality, or authenticity of data related to the technical operation of the TLD is compromised

Criterion	DNS service providers (CIR Art. 5)	TLD name registries (CIR Art. 6)
Complete unavailability	Significant after 30 minutes	Significant immediately — any total outage
Response time degradation	>10 seconds for >1 hour	>10 seconds for >1 hour
Data integrity compromise	Significant unless <1,000 domains / ≤1% of total (misconfiguration only)	Significant with no size exception

The stricter TLD threshold reflects the systemic importance of TLD availability: a ccTLD registry outage takes every domain under it offline simultaneously.

Once a significant incident is confirmed, Article 23 reporting obligations apply:

• 24 hours: Early warning to the national CSIRT or competent authority, indicating whether unlawful acts or cross-border effects are suspected
• 72 hours: Incident notification updating the early warning with severity assessment and available indicators of compromise
• One month: Final report detailing incident severity, impact, root cause, mitigation measures applied, and cross-border effects

Incident response procedures must be built around these deadlines before an incident occurs. The time between an alert and a 24-hour reporting deadline does not allow for drafting procedures from scratch.

Article 28: Registration Data Accuracy as a Structural Security Measure

Article 28 of NIS2 applies to TLD name registries and domain registration service providers. Its core obligation is that entities must collect and maintain accurate and complete domain name registration data in a dedicated database, with publicly disclosed verification procedures.

Required data elements include: domain name and registration date; registrant name, email address, and telephone number; and administrative contact information where different from the registrant.

The security dimension becomes clear when read against the DNS abuse context. Fast-flux and DGA-enabled C&C infrastructure frequently relies on domains registered with synthetic or falsified registrant data, making attribution and takedown extremely difficult. The verification obligation in Article 28 — implemented through documented and publicly disclosed procedures — is designed to close this gap at the registration layer.

Two additional obligations have operational impact:

• Access window: TLD registries and registrars must respond to substantiated access requests from legitimate requesters within 72 hours. This requires a documented and tested access request process in place before a law enforcement or CSIRT request arrives, not an ad hoc manual response.
• Public availability: Non-personal registration data must be made publicly available without undue delay via RDAP (Registration Data Access Protocol), the successor to WHOIS and the preferred technical mechanism under EU data protection law.

Where a ccTLD registry also operates domain registration services directly, both the TLD administration obligations (Article 6(21)) and the Article 28 registration data obligations apply concurrently. The verification procedures and access request workflow must be documented separately for audit purposes.

NIS2 DNS Compliance Checklist

Article 21(2) measure	DNS service provider actions	TLD registry actions	CIR reference
(a) Risk analysis	Identify DNS-specific threats: DGA flooding, fast-flux abuse, zone poisoning, resolver hijacking	Include TLD operational risks and DS record management in risk register	Annex Section 2
(b) Incident handling	Document classification using CIR Art. 5 thresholds; pre-written 24h/72h/1-month procedures	Stricter classification: any complete outage = significant; pre-written procedures for TLD failover	Annex Section 3; CIR Arts. 5–6
(c) Business continuity	Secondary nameserver diversity; tested failover; zone transfer monitoring	Multi-site anycast infrastructure; tested TLD failover with defined RTO	Annex Section 4
(d) Supply chain	Evaluate DNS software vendors and secondary nameserver providers; TSIG key management with third-party secondaries	Evaluate registry back-end providers; registrar security clauses addressing Article 28 data accuracy	Annex Section 5
(e) NIS acquisition & maintenance	DNSSEC implementation; zone transfer TSIG; resolver DNSSEC validation; Protective DNS	TLD zone signing; algorithm selection; key rollover; DS record publication to root zone	Annex Section 6.7.2(l)
(g) Cyber hygiene	Recursion restriction to authorised clients; resolver software patching cadence; staff DNS security training	PDNS filtering; employee training on social engineering targeting zone data	Annex Section 8
(h) Cryptography	DNSSEC key management policy (ZSK/KSK separation, rollover schedule, algorithm selection)	KSK ceremony procedures; DS record publication and emergency rollover protocol	Annex Section 9
(j) MFA	Administrative access to DNS management interfaces and zone editing tools requires MFA	Zone management portal, EPP interface, and IANA accreditation portal require MFA	Annex Section 11

Frequently Asked Questions

Does the CIR 2024/2690 specify DNSSEC as mandatory?

The CIR does not use the word “mandatory” for DNSSEC specifically. Section 6.7.2(l) requires “best practices for the security of the DNS.” ENISA’s Technical Implementation Guidance maps this to DNSSEC signing as the primary expectation for authoritative nameserver operators and TLD registries. In practice, an authoritative zone that is unsigned — particularly for a ccTLD registry — would be difficult to defend as “best practices” in an NIS2 audit.

Are ICANN and IANA in scope for NIS2 DNS obligations?

No. NIS2 Article 6(20) explicitly excludes root name servers from the definition of DNS service provider. ICANN’s root zone management functions and IANA’s operations are outside the directive’s scope. EU-based ccTLD registries are in scope; non-EU ccTLD registries serving EU users may also be subject to NIS2 where they have a sufficient EU nexus and must designate an EU representative.

What is the difference between CIR Article 5 and Article 6 thresholds?

Article 5 applies to DNS service providers and includes a 30-minute grace period before a complete outage becomes significant. Article 6 applies to TLD name registries and contains no such grace period — any complete unavailability of the TLD’s authoritative DNS service is immediately significant. The response time degradation threshold (>10 seconds for >1 hour) is identical across both articles.

Does Article 28 apply to generic TLD registries as well as ccTLDs?

Article 28 applies to all TLD name registries operating under or serving the EU market, including both ccTLD registries and gTLD operators with EU-based registration activities. The 72-hour access window and public RDAP availability requirements apply equally. Where ICANN’s registration data access policies create conflicts with Article 28, entities should seek legal advice on how to comply with both frameworks simultaneously.

Sources

1. NIS2 Directive Article 6 — Definitions (nis-2-directive.com)
2. NIS2 Directive Article 21 — Cybersecurity Risk Management Measures (streamlex.eu)
3. CIR 2024/2690 Annex — Technical and Methodological Requirements (Advisera)
4. CIR 2024/2690 Article 5 — Significant Incidents: DNS Service Providers (Advisera)
5. CIR 2024/2690 Article 6 — Significant Incidents: TLD Name Registries (Advisera)
6. NIS2 Directive Article 23 — Reporting Obligations (nis-2-directive.com)
7. NIS2 Directive Article 28 — Domain Name Registration Data (nis-2-directive.com)
8. CIR 2024/2690 — Official EC Library Entry (European Commission)
9. DNS Security in Focus: A Multistakeholder Path Forward Under NIS2 (Center for Cybersecurity Policy and Law)
10. ENISA NIS2 and DNS: Why the Plumbing Is Suddenly in the Spotlight (FutureScot / ENISA)

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.