Encrypted DNS protects a DNS query while it travels to a resolver. DNS filtering applies rules to the destination being requested. DNSSEC checks the authenticity and integrity of signed DNS data. These protections answer different questions, and an organization can use them together.
For an IT director or MSP, the practical issue is which resolver a managed device actually uses. A browser can have an encrypted connection to a DNS service without using the organization's intended filtering policy. A setting labeled “secure DNS” does not, by itself, establish that policy coverage.
Encryption protects the connection to the resolver
DNS translates names into information applications use to connect. DNS over HTTPS, usually called DoH, carries those DNS exchanges over HTTPS. It protects that exchange between the client and the selected DoH server; the resolver still receives the query. Choosing that operator remains a trust decision.
The IETF's DoH specification, RFC 8484 separates transport security from DNSSEC's protection of DNS data. An encrypted exchange does not independently prove that a DNS answer is authentic, and DNSSEC validation does not decide whether the destination is acceptable under your business's browsing policy.
Filtering decides which destinations to allow
Protective DNS evaluates lookups against threat information and policy. A service can block resolution for a domain associated with phishing, malware delivery, or attacker infrastructure. The UK National Cyber Security Centre's private-sector guidance describes how this approach can interrupt access to known harmful destinations.
That decision happens at the DNS layer. It is not a review of everything on a web page, every download, or every action a user takes after connecting. A permitted lookup should therefore be understood as one control's decision, not a clean bill of health for the whole session. Encryption and filtering can coexist when the selected service supports both.
A hypothetical browser shows why the path matters
Imagine a company whose managed laptops normally use its approved resolver. That resolver applies a policy blocking a particular test domain. An administrator then configures one browser to send DNS queries directly to a different DoH service, which does not have that company policy.
The browser's DNS traffic may now be encrypted, but the company's original resolver never receives those queries. If the browser resolves the test domain, that result does not establish that encryption defeated a filter. The query followed a different path to a different policy.
This is a hypothetical example, not a customer incident. In a real environment, a separate endpoint or web control might still block the connection. The useful investigation question is which component made each decision. “The site opened” and “the DNS request was encrypted” cannot answer that on their own.
Manage the resolver choice, including away from the office
NIST SP 800-81r3, published in March 2026, addresses encrypted DNS deployment and the need to keep applications from bypassing enterprise resolver controls. Browser and operating-system support varies. Central device configuration can be necessary; network rules alone are harder to apply to DoH traffic carried over HTTPS.
Define the approved resolver and the expected behavior on office, home, and roaming connections. For a practical acceptance demonstration, use the provider's harmless test domain on a representative managed device, then confirm the expected decision and its corresponding record. Repeat the demonstration off the office network. This provides evidence about the tested path, not a guarantee about every application or device.
Also agree what happens if the resolver is unavailable. The NCSC guidance highlights service availability, off-network coverage, and access to logs. A fallback that restores name resolution may have different filtering or reporting behavior. Record that tradeoff explicitly, along with who can access query logs and how long they are retained.
Place DNS policy alongside web protection
DNS policy and web inspection belong in the same coverage discussion. Network Box USA's managed Secure Web Gateway includes URL filtering, content policy, HTTPS inspection, and reporting. The appropriate design depends on the devices, traffic paths, inspection scope, and exclusions agreed for the environment.
Bring those details to a review of how users reach the web. If you need help assessing managed web protection, contact our team to discuss your environment and requirements.