DNS Security and Filtering

DNS security and filtering describe a category of network controls applied at the Domain Name System layer to block malicious resolution requests, prevent data exfiltration over DNS channels, and enforce organizational access policies before a network connection is established. Because DNS operates as the foundational lookup service for virtually all internet-bound traffic, it functions as both a high-value attack surface and a high-leverage enforcement point. This page covers the definition and scope of DNS security and filtering, the technical mechanisms that underpin it, the scenarios in which it is deployed, and the decision criteria that separate different control approaches.

Definition and scope

The Domain Name System translates human-readable domain names into IP addresses, following a recursive resolution process governed by standards published by the Internet Engineering Task Force (IETF RFC 1034 and RFC 1035). DNS security encompasses the set of controls designed to protect the integrity and availability of that resolution process and to intercept requests to known-malicious or policy-prohibited destinations.

NIST Special Publication 800-81-2, Secure Domain Name System (DNS) Deployment Guide, establishes the federal baseline for DNS security implementation, covering both DNS protocol hardening and operational security practices for resolvers and authoritative servers. The scope of DNS security as a discipline spans three distinct functional areas:

• Protocol integrity: Preventing spoofing and cache poisoning through DNSSEC (DNS Security Extensions), which uses cryptographic signatures to authenticate resolution responses (IETF RFC 4033).
• Filtering and sinkholing: Blocking or redirecting resolution requests that match threat intelligence feeds, category blocklists, or organizational access policies.
• Encrypted transport: Protecting DNS queries from interception via DNS over HTTPS (DoH, RFC 8484) or DNS over TLS (DoT, RFC 7858).

Federal agencies operating under Binding Operational Directive 18-02, issued by the Cybersecurity and Infrastructure Security Agency (CISA BOD 18-02), are required to implement DNSSEC for all second-level domains and to monitor DNS traffic for unauthorized changes.

How it works

DNS filtering operates by intercepting recursive resolution requests at a controlled resolver — either an on-premises DNS server, a cloud-delivered recursive resolver, or a DNS firewall appliance — before a response is returned to the requesting client. The filtering decision is applied at the resolution stage, meaning the network connection to a malicious or prohibited destination is never initiated.

The standard filtering workflow proceeds through the following discrete phases:

1. Request interception: A client device queries the configured resolver. In enterprise deployments, the resolver is operated or proxied by the organization rather than using a public upstream directly.
2. Threat and policy lookup: The queried domain is matched against one or more classification databases — threat intelligence feeds containing confirmed malware command-and-control (C2) domains, phishing domains, botnet infrastructure, or category-based blocklists covering content policy categories such as gambling or adult content.
3. Action enforcement: If a match is found, the resolver returns either a non-routable IP address (sinkhole), an NXDOMAIN response (domain does not exist), or a redirect to a block page. If no match is found, resolution proceeds normally.
4. Logging and telemetry: All DNS queries, matched or unmatched, are logged for security monitoring, forensic analysis, and compliance reporting.

DNSSEC validation operates as a parallel mechanism: rather than filtering by destination reputation, DNSSEC verifies that the resolution answer received from an upstream authoritative server carries a valid cryptographic signature chain tracing back to the DNS root, preventing cache poisoning attacks. DNSSEC and DNS filtering are complementary controls — one ensures response authenticity, the other enforces destination policy.

DNS-over-HTTPS and DNS-over-TLS add a third control dimension by encrypting the query-and-response transaction between client and resolver, preventing passive surveillance or on-path manipulation of DNS traffic at the transport layer. The NSA Cybersecurity Information Sheet on Encrypted DNS (January 2021) outlines the tradeoffs enterprises face when deploying encrypted DNS protocols, including reduced visibility at network monitoring layers.

Common scenarios

DNS security and filtering controls appear across distinct deployment contexts, each carrying different technical and regulatory requirements. Professionals navigating the network security providers will encounter providers and practitioners aligned to these scenarios:

Enterprise access control: Organizations deploy DNS filtering at the recursive resolver level to block access to threat categories — confirmed malware domains, newly registered domains with no established reputation, and domains flagged by threat intelligence sharing communities such as those coordinated through the Cybersecurity and Infrastructure Security Agency. This scenario represents the most common enterprise use case.

Incident response and threat containment: When a malware infection is identified, DNS-based sinkholing redirects C2 traffic from infected endpoints to an analyst-controlled IP, allowing continued traffic analysis without permitting actual C2 communication. This technique is documented in MITRE ATT&CK under the Network Traffic: DNS sub-technique classification.

Regulated industry compliance: Healthcare organizations governed by the HIPAA Security Rule (45 CFR Part 164) and financial institutions subject to FFIEC guidance are expected to implement controls preventing access to known-malicious infrastructure; DNS filtering satisfies part of that technical safeguard requirement.

Managed service provider (MSP) environments: DNS filtering deployed by MSPs enforces policy boundaries across multi-tenant environments, with per-client policy segmentation applied at the resolver level.

Decision boundaries

Selecting between DNS security control types requires distinguishing the threat model each addresses. The comparison between DNSSEC, DNS filtering, and encrypted DNS transport is frequently conflated — these are not interchangeable.

Organizations considering DNS filtering as a standalone control should account for the following decision thresholds:

• Encrypted DNS bypass: Endpoints using hardcoded DoH resolvers (such as those built into browser configurations) can bypass enterprise DNS filtering entirely unless explicit firewall rules or split-horizon DNS configurations intercept or redirect encrypted DNS traffic.
• Logging retention requirements: Regulatory frameworks including the FFIEC IT Examination Handbook and NIST SP 800-92 (Guide to Computer Security Log Management) specify log retention standards; DNS query logs generated by filtering infrastructure must be retained in alignment with the applicable requirement.
• False positive tolerance: Aggressive filtering using newly-registered domain blocklists can generate false positives at a rate that disrupts legitimate business operations. The CISA Protective DNS program — available to federal civilian executive branch agencies — publishes operational guidance for tuning filter sensitivity.
• DNSSEC coverage gap: DNSSEC requires both the authoritative zone operator and the recursive resolver to support and enforce validation. As of 2023, the Internet Society's DNSSEC deployment maps indicate uneven deployment across top-level domains, leaving portions of the domain namespace without cryptographic validation coverage regardless of resolver configuration.

The network security provider network purpose and scope provides context on how DNS security fits within the broader structure of network protection services verified in this reference. For organizations evaluating providers, the how to use this network security resource page describes the classification framework applied to verified services.