Domain Name System filtering is a security control that blocks or redirects DNS lookups for domains on a policy list. It works at the name resolution layer, so devices can be stopped from reaching known malicious, phishing, or unwanted destinations before a connection is made.
How DNS Filtering Works
DNS filtering is usually enforced at the resolver or security gateway layer, where policy decides whether a queried domain is allowed, blocked, or redirected. Because the control acts before the connection is established, it can stop access to malicious destinations without inspecting every application protocol in detail. That makes it an efficient first line of defence, especially for broadly distributed user and device fleets.
In practice, DNS filtering is often implemented as denylisting, allowlisting, or response-policy redirection. A blocked lookup may return an error, a sinkhole address, or a safe landing page, depending on the organisation’s design. The mechanism is simple, but its value depends on policy quality, resolver coverage, and how well the control is enforced across roaming users, remote networks, and unmanaged devices.
Why DNS Filtering Matters
DNS is one of the most leveraged layers in the internet stack because almost every networked application depends on name resolution. Filtering at this layer can reduce exposure to phishing pages, malware infrastructure, command-and-control domains, and other unwanted destinations before a user agent ever opens a connection. It is also useful for enforcing acceptable-use policy and reducing access to categories of content that the organisation does not want reachable from managed endpoints.
The main strength of DNS filtering is that it creates a broad control point with relatively low user friction. The main weakness is that it only protects traffic that actually uses the organisation’s resolvers and policies. If endpoints can bypass those resolvers, or if encrypted DNS is allowed without governance, the control can become inconsistent. A DNS control is therefore strongest when it is part of a wider Protective DNS Guide approach that covers forwarding, enforcement, and monitoring.
Common Deployment Models and Control Boundaries
DNS filtering can sit on an endpoint agent, a local network gateway, a cloud resolver, or a security service that forwards queries to a policy engine. Each model shifts the trust boundary slightly. Endpoint-based filtering follows the device, while network-based filtering is easier to centralise but can be evaded off-network unless remote traffic is also forced through the same control plane.
Policy scope also matters. Some organisations block only clearly malicious domains, while others extend filtering to risky newly registered domains, domains associated with ads or trackers, or categories that create business or legal exposure. The more expansive the policy, the more important it becomes to document exceptions, because over-blocking can interfere with legitimate software updates, identity flows, and SaaS dependencies. For that reason, implementation often needs to align with a broader CIS Control 9 Email and Web Browser Protections Guide mindset rather than treating DNS filtering as a standalone toggle.
How DNS Filtering Fits With Related Security Controls
DNS filtering is most effective when paired with logging, threat intelligence, and other outbound filtering controls. DNS logs can reveal repeated lookups for algorithmically generated domains, failed resolution attempts, and suspicious spikes that may indicate malware activity or policy bypass. It can also complement URL filtering, sandboxing, and network egress controls when the same destination is reachable through multiple protocols or applications.
It also has a useful relationship with the resolver ecosystem itself. DNS control depends on authoritative naming and routing infrastructure, so understanding registry and protocol context can help teams distinguish legitimate resolution behaviour from abuse patterns. When organisations need to reason about resolver trust, record handling, or name infrastructure, the broader Internet coordination layer described by IANA is the relevant reference point.
Risk and Threat Considerations
DNS filtering reduces exposure, but it is not a complete prevention layer. Adversaries can try to bypass it with encrypted DNS, hard-coded IPs, alternate resolvers, or tunnels that hide inside allowed traffic. If the organisation does not control resolver choice and outbound paths consistently, the filtering policy may exist on paper while being only partially enforced in reality.
Failure mechanism: The control fails when endpoints can evade the organisation’s approved resolver path, or when logging and policy updates are too weak to catch newly weaponised domains quickly enough.
Impact: Users may still reach phishing, malware, and command-and-control infrastructure, and defenders may lose a valuable early-warning signal that would otherwise show suspicious lookup behaviour before compromise spreads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | DNS filtering is a named safeguard under Control 9 for web and email threat reduction. |
| Recommendation — Implement DNS filtering to block risky destinations before users reach them. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | DNS filtering enforces egress policy at the network boundary and name-resolution layer. |
| SI-3 — Malicious Code Protection | Blocking malicious domains helps prevent malware retrieval and callback infrastructure use. | |
| Recommendation — Apply boundary protection to restrict outbound DNS paths and policy bypass. Use malicious code protection controls to block domain lookups tied to known threats. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | DNS filtering depends on resolver and bypass configuration being correct and consistently enforced. |
| Recommendation — Harden DNS resolver configuration so filtering cannot be bypassed by misconfiguration. | ||
| MITRE ATT&CK | T1071.004 — Application Layer Protocol: DNS | DNS is a common command-and-control and tunnelling channel that filtering seeks to disrupt. |
| Recommendation — Hunt for DNS-based command-and-control and tunnelling activity in telemetry. | ||
Practitioner Guidance
Why practitioners should care: DNS filtering is often the cheapest broad control for reducing outbound exposure, but only if it is enforced consistently across office, remote, and cloud-connected environments. Treat coverage and bypass prevention as part of the control definition, not as optional extras.
What to watch for: Monitor for resolver drift, unexpected use of public DNS services, repeated NXDOMAIN patterns, and destinations that should have been blocked but still appear in endpoint or proxy telemetry. Those signals often show where policy scope, enforcement, or logging needs adjustment.
Practitioner takeaway: The control works best when policy, enforcement, and telemetry are designed together, because blocking without visibility is hard to trust and visibility without enforcement is easy to bypass.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org