Protective DNS increasingly appears in security guidance as more than basic network infrastructure. It can enforce domain policy at name resolution, ahead of most new connections, block known malicious destinations, and produce DNS telemetry that supports investigation and control verification.
Compliance language still matters. Some guidance explicitly recommends or requires DNS filtering. Other frameworks describe security outcomes without naming a particular technology. Treating those two cases as equivalent makes a compliance claim stronger than the source material supports.
NIST now gives protective DNS explicit deployment guidance
NIST Special Publication 800-81 Revision 3, published in March 2026, gives protective DNS a direct role in enterprise security architecture. Its high-level recommendations tell network and security owners to employ protective DNS wherever technically feasible.
NIST identifies several capabilities that protective DNS can provide:
- Blocking harmful or malicious traffic in real time
- Filtering categories of traffic that conflict with organizational policy
- Generating real-time and historical DNS query and response data for digital forensics and incident response
- Integrating DNS with defense-in-depth and zero trust security architectures
- Helping organizations meet regulatory or contractual responsibilities that require traffic to disallowed sites to be blocked
This is stronger than simply observing that DNS can be useful for security. SP 800-81r3 treats protective DNS as a recommended enterprise security control and provides deployment guidance around it.
CIS makes DNS filtering a measurable safeguard
The CIS Critical Security Controls are more prescriptive at the safeguard level. CIS Controls v8.1 includes Safeguard 9.2, “Use DNS Filtering Services.”
The safeguard calls for DNS filtering on end-user devices, including remote and on-premises assets, to block access to known malicious domains. CIS places the safeguard in Implementation Groups 1, 2, and 3, so it is part of the baseline set applied across the CIS implementation model rather than being reserved for only the most mature environments.
The companion CIS Controls Assessment Specification pairs the safeguard with a DNS Filtering Coverage metric: the proportion of enterprise assets capable of supporting DNS filtering that are properly configured to use authorized DNS filtering services. That measures configuration coverage rather than traffic, so demonstrating that applications can’t bypass the authorized DNS path takes additional evidence. The intent behind the metric is still operational rather than nominal. A filtering service protects only the queries that actually reach it.
NIST CSF 2.0 leaves the implementation choice open
The NIST Cybersecurity Framework 2.0 works differently from a deployment guide or detailed safeguard catalog. The CSF describes cybersecurity outcomes an organization can use to manage risk. NIST states that the framework doesn’t prescribe how those outcomes must be achieved.
Protective DNS can support CSF outcomes by enforcing policy, reducing connections to known malicious infrastructure, providing DNS visibility, and supplying information used during detection and response. The framework itself doesn’t turn protective DNS into a universal CSF requirement.
When documenting controls, an organization can therefore explain how protective DNS contributes to a CSF outcome without claiming that the CSF mandates a particular DNS product, architecture, or filtering method.
Federal civilian agencies show what an explicit requirement looks like
U.S. Federal Civilian Executive Branch agencies provide a narrower example where DNS requirements are explicit rather than merely supportive.
CISA’s Encrypted DNS Implementation Guidance states that these agencies are required to use CISA’s Protective DNS capability for all egress DNS resolution. The guidance also addresses encrypted DNS and the need to prevent endpoints and applications from bypassing the authorized DNS path by communicating directly with third-party resolvers.
That requirement is specific to the federal agencies covered by the cited authorities. It shouldn’t be generalized into a requirement for private organizations, state governments, or other environments.
Frameworks ask different questions of the same DNS control
The same protective DNS deployment can play different roles depending on the framework or requirement being evaluated.
| Source | DNS treatment | Practical question |
|---|---|---|
| NIST SP 800-81r3 | Recommends protective DNS wherever technically feasible | Is protective DNS part of the enterprise DNS and security architecture? |
| CIS Controls v8.1, Safeguard 9.2 | Calls for DNS filtering on end-user devices | Are applicable assets configured to use authorized DNS filtering? |
| NIST CSF 2.0 | Defines outcomes rather than a required DNS technology | Which cybersecurity outcomes does the DNS control support? |
| CISA FCEB guidance | Specifies Protective DNS requirements for covered federal agencies | Is egress DNS following the authorized federal resolution path? |
This is why “compliance with DNS filtering” is too broad a statement on its own. The relevant question is which requirement applies, what it actually says, and what evidence demonstrates that the DNS control is operating within the required scope.
Enforcement and evidence are separate compliance functions
Protective DNS can contribute to compliance in two different ways.
The first is enforcement. A resolver can apply rules to malicious domains, prohibited categories, or explicitly disallowed destinations. For acceptable use and contractual restrictions, DNS filtering can translate domain-level policy into resolver decisions.
The second is evidence. DNS query and response logs can show that clients are using the expected resolver, that a policy rule was applied, and that a malicious or disallowed domain was blocked. Historical data can also support incident response and post-event investigation, which NIST SP 800-81r3 explicitly identifies as a protective DNS capability.
Evidence quality depends on architecture. Logs from a resolver prove little about endpoints that bypass it. A compliance program therefore needs to understand resolver coverage, endpoint configuration, encrypted DNS behavior, retention, time synchronization, identity mapping, and any gaps between intended and actual DNS paths.
Coverage is part of the control
Installing a protective DNS resolver somewhere in the environment doesn’t establish that every relevant query passes through it.
Remote endpoints, guest networks, cloud workloads, mobile devices, applications with their own resolver settings, and encrypted DNS can create alternate resolution paths. The CIS assessment model reflects this operational problem by measuring the assets configured to use authorized DNS filtering rather than treating the existence of a service as sufficient evidence.
The same reasoning applies outside CIS. If a policy depends on DNS enforcement, the organization needs to know which systems are in scope and how those systems are directed to the intended resolver. The DNS filtering mechanism only evaluates queries that reach the policy-enforcing component.
Compliance still depends on the underlying obligation
A protective DNS deployment can satisfy a specific technical safeguard, support a broader security outcome, or provide evidence for a policy requirement. Those are meaningful contributions, but they aren’t interchangeable.
Regulations, contracts, frameworks, and internal standards differ in scope and language. A control that aligns well with NIST SP 800-81r3 or CIS 9.2 may be only one part of a much larger program involving identity, access control, endpoint security, logging, incident response, governance, and audit evidence.
The defensible approach is to trace the requirement to its source, identify the DNS behavior that contributes to it, and document the evidence showing that the control actually covers the intended systems.
Summary
Protective DNS has moved into explicit security guidance. NIST SP 800-81r3 recommends it wherever technically feasible, CIS Controls v8.1 includes DNS filtering as a measurable safeguard, and federal civilian agencies operate under specific Protective DNS requirements. Outcome-based frameworks such as NIST CSF 2.0 leave the technology choice open while still giving DNS controls a place to support broader security objectives.
The useful compliance question isn’t whether protective DNS carries a generic compliance label. It’s how a specific DNS control maps to a specific requirement, how broadly that control is enforced, and what evidence proves that it’s working.