Who should read this: DNS operators, internet infrastructure teams, TLD registry operators, ISP technical leaders, domain registrars, compliance teams.
The Domain Name System (DNS) is invisible to most internet users but essential to everyone. When you type a domain name into a browser, DNS translates it to the IP address of the server you want to reach. It happens in milliseconds, billions of times per day, globally. Despite its critical role, DNS has often been treated as an administrative detail, important but not a primary security focus. The NIS2 Directive changes this. The Directive recognises DNS as foundational infrastructure and subjects DNS operators to stringent security requirements. This post explains why NIS2 treats DNS as critical, how the Directive applies to DNS operators, and what security readiness means in practice.
The importance of DNS to internet stability and security cannot be overstated. If DNS is compromised, an attacker can redirect users away from legitimate websites to fraudulent ones, intercept traffic bound for banks or government services, or disrupt entire sectors by poisoning DNS records. A large-scale DNS failure does not need to be malicious to cause harm. A misconfiguration, a software bug, or a distributed denial of service attack can knock DNS offline, making large portions of the internet unreachable. The 2016 Dyn cyber attack, which exploited weaknesses in DNS infrastructure, demonstrated that even brief DNS disruptions can bring down major services globally.
Recognising this, Recital 32 of the NIS2 Directive states: “Upholding and preserving a reliable, resilient and secure domain name system (DNS) are key factors in maintaining the integrity of the internet and are essential for its continuous and stable operation, on which the digital economy and society depend. Therefore, this Directive should apply to top-level-domain (TLD) name registries, and DNS service providers that are to be understood as entities providing publicly available recursive domain name resolution services for internet end-users or authoritative domain name resolution services for third-party usage.” The Directive does not apply to root name servers, which operate under separate governance. But the scope is otherwise comprehensive: any organisation that operates DNS infrastructure accessible to the public falls within NIS2.
Who Is Covered by NIS2 DNS Requirements?
The Directive defines two categories of DNS operators subject to NIS2:
- Top-level-domain (TLD) name registries: These are the operators of domain extensions like .eu, .de, .com, .org. A TLD registry maintains the authoritative records for all domains under that extension. It manages the database, delegates domains to registrars, and handles the technical infrastructure that allows the rest of the DNS system to function.
- DNS service providers: These are entities providing either publicly available recursive domain name resolution services (the systems that resolve domain names for end-users) or authoritative domain name resolution services (the systems that provide definitive answers for specific domains to other DNS servers). Major internet service providers, cloud providers, and specialised DNS companies typically operate these services.
The scope is intentionally broad because DNS is a foundational layer. Even a small DNS service provider serving a few thousand users is included because a compromise at that layer could affect those users and potentially propagate beyond them. Conversely, the Directive explicitly excludes root name servers, which are managed under different governance structures and benefit from a different level of oversight.
For TLD registries, this means that even if you operate a smaller TLD, perhaps serving a geographic region or a specific community, you are now subject to NIS2. You must implement security measures, report significant incidents, respond to cyber threats, and undergo security audits. This is a step change for many registries that previously had minimal regulatory interaction with cybersecurity requirements.
For DNS service providers, the scope includes global players like Cloudflare, Google Public DNS, and Quad9, but also smaller providers. Any ISP offering DNS resolution to its customers, any managed DNS service provider, and any cloud provider offering DNS as part of its service portfolio falls within scope.
Why Is DNS So Critical?
DNS is critical for several reasons that NIS2 recognises implicitly:
- Universal dependency: Nearly every internet communication starts with a DNS query. Email, web browsing, cloud services, IoT devices, all depend on DNS working correctly. Unlike more specialised infrastructure, DNS is used ubiquitously.
- Trust anchor: Users trust that when they type a domain name, they reach the intended destination. This trust is fragile. If DNS is compromised silently, users may not realise they are interacting with a malicious version of a website. Phishing attacks often exploit DNS weaknesses by hijacking domain names or using lookalike domains that DNS does not prevent.
- Resilience burden: The internet has made DNS resilience a shared responsibility. If a major DNS provider goes offline, millions of users lose internet access. There are fallback mechanisms (users can switch to another DNS provider) but they require user action. Meanwhile, the disruption is real.
- Attack surface: Because DNS is so widely used, it is a tempting attack target. Attackers can poison DNS caches, redirect traffic, or conduct denial of service attacks against DNS infrastructure. The technical sophistication required is lower than for many other attacks; the payoff, in terms of reach and impact, is enormous.
- Supply chain implications: DNS is deeply integrated into the supply chains of critical sectors. Financial institutions rely on DNS to route customer traffic to their servers. Healthcare systems use DNS to reach patient records. Power grids use DNS for operational communications. A DNS failure cascades into failures across these sectors.
NIS2 Security Requirements for DNS Operators
NIS2 subjects DNS operators to the same cybersecurity risk management framework as other important entities. Article 21 of the Directive requires important entities to implement technical, organisational and operational measures to manage cybersecurity risks. The specific requirements depend on the context, but they include:
- Access control and authentication: Limiting who can modify DNS records, change configuration, or access DNS infrastructure. Multi-factor authentication for administrators. Role-based access control so that staff can only access what they need.
- Encryption: Using encryption for DNS query responses, particularly DNSSEC (Domain Name System Security Extensions), which cryptographically signs DNS records so clients can verify they have not been tampered with. Encryption in transit for administrative communications and data transfer.
- Logging and monitoring: Recording all DNS queries and changes to DNS records. Detecting anomalies, such as sudden spikes in query volume, suspicious patterns of record modifications, or unusual administrative logins.
- Incident detection and response: Identifying when DNS is under attack or has been compromised. Having procedures to respond rapidly, including isolating affected infrastructure, restoring from clean backups, and notifying customers.
- Distributed infrastructure: Placing DNS servers geographically so that a failure in one location does not take down the entire service. Using anycast routing so users are directed to the nearest functioning server. Maintaining redundancy across multiple internet exchange points and carriers.
- DDoS mitigation: Protecting DNS infrastructure against distributed denial of service attacks. This includes rate limiting, traffic filtering, and capacity planning so that normal traffic is served even during attacks.
- Software and firmware updates: Keeping DNS software current so that known vulnerabilities are patched. Testing updates in staging environments before deploying to production, so updates do not introduce new problems.
- Supply chain management: Assessing the security of vendors who supply DNS software, hardware, or services. Ensuring that vendors meet baseline security standards and respond promptly to vulnerabilities.
Reporting Obligations for DNS Operators
Article 23 of the NIS2 Directive requires essential and important entities, including DNS operators, to report significant incidents without undue delay and in any event within 24 hours of becoming aware of the incident. A significant incident is one that “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned” or “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.”
For a DNS operator, what qualifies as significant? A DNS service that is completely offline or severely degraded for hours would clearly qualify. A successful cyber attack that compromised DNS records, even if detected and remedied quickly, would likely qualify because of the potential for users to be redirected to fraudulent sites. An attack that is detected and blocked without any impact on users would probably not qualify. The operator must assess, using professional judgment and documented criteria.
The reporting obligation creates transparency about DNS security incidents. Member States and coordinating agencies know when DNS incidents occur, how they were handled, and whether they had broader impact. This allows authorities to identify patterns: if multiple DNS operators are attacked with similar techniques, that is a signal of a wider threat. It also allows operators to learn from each other’s incidents.
Reporting is not punitive. The Directive explicitly states that “the mere act of notification shall not subject the notifying entity to increased liability.” This is important because operators might otherwise be tempted to conceal incidents. The Directive aims to encourage rapid reporting and information sharing, knowing that speed of response is critical to limiting damage.
DNSSEC and Cryptographic Signing
One of the most important technical measures for DNS operators under NIS2 is DNSSEC (Domain Name System Security Extensions). DNSSEC allows DNS operators to cryptographically sign DNS records so that resolvers and clients can verify that records have not been tampered with. Without DNSSEC, an attacker who gains network access between a client and a DNS server can inject false responses without detection. With DNSSEC, such tampering is immediately obvious because the cryptographic signature will not validate.
DNSSEC is not new; it has existed for years, but deployment has been slow. Many TLD registries and DNS operators have implemented it, but adoption among domain owners has lagged. NIS2 does not mandate DNSSEC explicitly, but it is clearly part of the “encryption” and “security by design” principles that the Directive emphasises. DNS operators will face pressure from regulators and customers to implement DNSSEC if they have not already. The Directive positions DNSSEC as a best practice aligned with NIS2 security objectives.
Coordinated Vulnerability Disclosure for DNS
The NIS2 Directive includes provisions for coordinated vulnerability disclosure, a process through which security researchers can report vulnerabilities to vendors before disclosing them publicly. This is critical for DNS software. DNS software runs on billions of devices globally. A vulnerability in widely-used DNS software could affect millions of users simultaneously. Coordinated disclosure allows the vendor to develop and deploy fixes before attackers know about the vulnerability.
For DNS operators, this means establishing a process to receive vulnerability reports from security researchers, handling them confidentially, coordinating with vendors on fixes, and deploying patches before the vulnerability becomes public knowledge. This is not a trivial process; it requires clear communication, defined timelines, and the ability to deploy updates rapidly to production systems. But it is essential for maintaining DNS security.
Key Takeaways
- NIS2 designates DNS as critical infrastructure, placing TLD registries and DNS service providers directly within the Directive’s scope as important entities.
- DNS security matters because DNS is universally depended upon; any compromise or disruption cascades across internet services and critical sectors.
- DNS operators must implement comprehensive cybersecurity measures including access control, encryption, monitoring, incident response, distributed architecture and DDoS mitigation.
- Significant DNS incidents must be reported within 24 hours to competent authorities, with reporting creating transparency about threats without imposing liability on operators.
- DNSSEC (cryptographic signing of DNS records) is a key technical measure aligned with NIS2’s encryption and security-by-design principles.
