For years, DNS sat in an awkward place in security conversations. Everyone relied on it; few wanted to talk about it. When regulations appeared, they tended to focus on higher level principles, while DNS was quietly left to networking teams.
That has changed. With the EU’s NIS2 Directive and ENISA’s Technical Implementation Guidance, DNS is now explicitly called out as part of the cybersecurity risk management story, not just a background service. At the same time, NIST’s updated SP 800-81 Secure DNS Deployment Guide treats DNS as a foundational security control, not just a naming service.
For public sector organisations in Scotland and across Europe, that combination matters: NIS2 sets the obligations, ENISA explains what “good” looks like, and NIST provides the technical playbook.
No matter if your organisation is a regulated entity under NIS2 or not – this is a glimpse into the future of many cyber regulations. This can be seen by ENISA providing a mapping from NIS2 to ISO27001:2022, NIST Cybersecurity Framework v2.0, ETSI Standard EN 319 401 V3.1.1 and others. There are common themes, such as resilience, across all regulatory frameworks.
What ENISA actually says about DNS
ENISA’s NIS2 technical implementation guidance is long, but the DNS story is quite concrete. In section 6.7, it points to a set of DNS security good practices that are “indicative, not exhaustive”, but give a very clear direction:
- Deploy DNSSEC
- Deploy protective DNS wherever technically feasible
- Encrypt DNS traffic, internal and external
- Use dedicated DNS servers
- Follow recognised deployment guidance
In other words, ENISA has moved DNS from “nice to have” to a named part of how you demonstrate cyber risk management under NIS2. And they are even explicitly referencing NIST SP 800-81 so let us have a look at this.
NIST SP 800-81: the DNS deployment guide
Where ENISA focuses on guidance for implementing NIS2 as a whole, NIST SP 800-81 focuses on how to run DNS services in a way that meets those expectations in practice. The draft update expands beyond classic topics like DNSSEC to recognise DNS as a security control in its own right, underpinning zero trust and Protective DNS use cases.
A few themes from SP 800-81 that map directly onto ENISA’s guidance and NIS2 obligations are:
- DNS hygiene – continuously monitoring for misconfigurations, dangling CNAMEs, lame delegations and lookalike domains that can be abused by threat actors.
- Protective DNS – using DNS as the first control point to block connections to known or suspected malicious infrastructure before an attack can progress.
- Logging and telemetry – treating DNS query and response data as a primary source for incident response, threat hunting and regulatory reporting timelines.
For Scottish public sector teams, this is useful because it gives you a concrete, globally recognised baseline that ENISA itself references and that can help you make your case when regulators come to audit you.
What this means in a real public sector network
Any regulated entity may not fully comply with regulations when they come into force, but will need a roadmap to a compliant state, demonstrating that any gaps have been identified and there is a plan to close these. The ENISA Technical Implementation Guidance for NIS2 includes “adopt an implementation plan for the full transition towards latest generation network layer communication protocols in a secure, appropriate and gradual way and establish measures to accelerate such transition” and in the same section “apply best practices for the security of the DNS”
A practical roadmap might look like this:
- Make DNS resilient by design
Ensure critical DNS services aren’t a single point of failure: run at least two independent DNS resolution paths (for example, resolvers in different sites or clouds) and consider implementing separation of duties for critical services such as DNS services so they are on dedicated systems.
- Raise the bar on DNS hygiene
Put in place regular checks for stale records, dangling domains and misconfigurations that could be abused. This directly supports NIS2’s focus on risk management and supply chain resilience.
- Introduce or strengthen protective DNS
Whether provided nationally or deployed locally, Protective DNS gives you a measurable way to show you are blocking known bad destinations and enforcing acceptable network use policies.
- Treat DNS logs as evidence of what is happening on your networks
Align your DNS logging strategy with incident response and reporting obligations, so the same telemetry that helps your SOC threat hunt also helps support notification and audit requirements.
Compliance without unnecessary complexity
Across NIS2, ENISA and NIST, a pattern emerges: regulators and standards bodies are converging on a common set of DNS best practices that can be reused across mandates – NIS2, DORA, national guidance and beyond. This can be seen in the recently established EU multi-stakeholder Forum on Internet Standards Deployment, which has a workstream on DNS security.
For public sector organisations, the opportunity is to invest in getting DNS “done right” – resilient architecture, good hygiene, Protective DNS and usable logging – then leverage that foundation to tick multiple regulatory boxes and, more importantly, genuinely improve cyber resilience and business continuity.
It might not be the most glamorous part of the stack, but as NIS2 and ENISA now make clear: if you want resilient services and defensible compliance, DNS is an essential part.
