“We enabled encrypted DNS” sounds like a completed security project. It is not. DNS over HTTPS (DoH) and DNS over TLS (DoT) protect DNS traffic in transit, while protective DNS uses the resolver as a security control to block or observe harmful destinations. One answers “can someone on the path read or alter this query?” The other asks “should this name resolve at all?”
Organizations deciding between DoH, DoT, and protective DNS should avoid treating them as mutually exclusive products. The practical design usually combines encrypted transport, an approved recursive resolver, filtering, useful logging, and controls that stop applications from quietly choosing an unmanaged resolver.
Definition
DoT carries the traditional DNS protocol inside TLS. RFC 7858 assigns TCP port 853 by default. The dedicated port makes the traffic easier to identify and control at network boundaries, though that also makes it easier to block.
DoH maps DNS exchanges to HTTPS. RFC 8484 uses normal HTTP mechanisms over TLS, generally on port 443. This can traverse networks that permit ordinary web traffic and can integrate naturally with browsers and applications. It can also make unmanaged resolver use harder to distinguish from other HTTPS traffic.
Protective DNS analyzes queries and responses and applies security policy. NIST describes it as a service that can block malicious websites and disrupt malware, ransomware, phishing, spyware, and other threats. It may run on internal infrastructure, in a cloud service, or as a hybrid.
How DoH, DoT, and protective DNS work together
An endpoint sends a query to a recursive resolver. DoH or DoT encrypts that client-to-resolver path and can authenticate the resolver, reducing on-path eavesdropping and tampering. The approved resolver then performs or forwards resolution.
Protective DNS adds policy at that resolver. It can compare a domain with threat intelligence or organizational rules, refuse resolution, redirect to a controlled response, and record the event for investigation. Response Policy Zones and DNS firewalls are common enforcement mechanisms.
The authoritative DNS side of an organization is a separate concern. Encrypted stub-to-recursive traffic and protective recursive resolution do not automatically secure domain registration, authoritative servers, zone transfers, DNSSEC, or dangling records. Include those roles in the wider DNS program even though this comparison focuses on user and workload resolution.
Encryption does not guarantee that the resolver is trustworthy, privacy-preserving, centrally managed, or able to block malicious destinations. Filtering does not guarantee that the path to the resolver is private. That is why mature deployments combine the two.
Why it matters
Traditional DNS can expose browsing and application patterns to networks on the path and can be modified by an on-path attacker. Encrypted DNS protects confidentiality and integrity between the client and selected resolver.
Meanwhile, many attacks still need domain resolution for phishing, command and control, payload delivery, or data exfiltration. NIST notes that protective DNS can stop communication before a malicious stream begins and provide historical query data for digital forensics and incident response.
Comparison
| Capability | DoH | DoT | Protective DNS |
|---|---|---|---|
| Encrypts client-to-resolver traffic | Yes, over HTTPS | Yes, over TLS | Only when paired with encrypted transport |
| Typical port | 443 | 853 | Depends on transport and architecture |
| Blocks malicious domains | Not inherently | Not inherently | Yes, when policy and intelligence support it |
| Easy network identification | Harder because it resembles web traffic | Easier because it uses a dedicated port | Depends on deployment |
| Central policy and logging | Only with a managed resolver | Only with a managed resolver | Core design goal |
| Primary benefit | Privacy and integrity with application-friendly transport | Privacy and integrity with distinct DNS transport | Threat prevention, visibility, and enforcement |
Examples
Managed laptops
Configure the operating system or security agent to use the organization’s protective resolver over DoH or DoT. Enforce the setting on and off network, and prevent browsers from selecting arbitrary public resolvers. Preserve client identity so blocked queries can be traced to a device or user.
Legacy devices and IoT
Some devices cannot speak encrypted DNS. Send traditional DNS to a controlled local forwarder, then use encrypted transport from the forwarder to the approved resolver. Restrict direct outbound DNS so devices cannot bypass the path.
Branch offices
A local forwarder can provide caching, resilience, and device attribution while forwarding to a cloud protective service. Decide explicitly whether failure should block resolution, fall back to another protected resolver, or fail open. Availability behavior is a security decision.
Cloud workloads and containers
Cloud platforms, Kubernetes clusters, service meshes, and serverless workloads may use platform-specific resolvers and search domains. Map these paths separately from employee endpoints. Preserve internal service discovery while forwarding appropriate external queries through protective controls.
Guest and bring-your-own-device networks
Guest networks may prioritize privacy and isolation over user attribution. Publish clear terms, separate them from managed networks, and decide whether to offer an encrypted protective resolver without forcing personal devices into corporate monitoring. The right balance depends on ownership and stated policy.
Limitations and tradeoffs
Resolver trust moves rather than disappears
Encryption hides queries from the local network path, but the recursive resolver still processes them. Review provider privacy terms, retention, jurisdiction, access controls, subcontractors, and incident history. For internal resolvers, apply the same rigor to administrators and logs.
DoH can bypass enterprise controls
An application that chooses its own DoH resolver may bypass filtering, split-horizon names, incident telemetry, and policy. Use managed browser settings, endpoint controls, canary mechanisms where supported, resolver allowlists, and network policy to keep encrypted DNS under governance.
DNS filtering is not complete web filtering
Protective DNS sees names and responses, not every URL, file, or encrypted application action. Attackers may use compromised legitimate domains, direct IP connections, fast-changing infrastructure, or DNS-independent channels. Keep endpoint protection, email security, web controls, identity defenses, and segmentation.
Logging creates privacy and cost questions
NIST recommends robust DNS logging for regulated and government environments but acknowledges the performance and storage cost. Queries involving malicious or unauthorized domains should be retained for security objectives. Define selective logging, retention, access, and deletion rules before collecting everything indefinitely.
False positives can interrupt work
Threat intelligence and category filters are imperfect. Establish an exception process with ownership, review, expiration, and evidence. Do not teach users to switch to an unmanaged resolver whenever a site is blocked; give them a safe way to request validation.
Availability and captive portals need testing
Encrypted DNS can behave differently on hotel, airport, and public Wi-Fi networks that require a captive portal. VPN transitions and resolver outages can also create confusing failures. Define fallback behavior deliberately and monitor it so a temporary outage does not produce a permanent bypass.
Architecture decision criteria
- Control: Can administrators enforce the resolver on browsers, operating systems, mobile devices, and workloads?
- Privacy: Who can see queries, how long are they retained, and for what purposes are they used?
- Attribution: Can a malicious query be linked to an asset or user with appropriate safeguards?
- Resilience: Are multiple resolvers, regions, or local forwarding paths available, and what happens on failure?
- Coverage: Does the service inspect relevant record types and work for roaming endpoints?
- Operations: Can blocks, threat intelligence, and logs integrate with existing incident-response tools?
- Compatibility: Will internal names, split DNS, VPNs, legacy devices, and cloud service discovery continue to work?
What should you deploy?
- Map actual resolution paths. Test browsers, operating systems, VPN clients, containers, mobile devices, guest networks, and cloud workloads.
- Select approved resolvers. Decide who operates them, what they log, how they fail, and how clients authenticate them.
- Enable encrypted transport. Choose managed DoH or DoT based on platform support and control requirements; mixed environments can use both.
- Add protective policy. Use threat intelligence, DNS firewalls or RPZs, and category rules appropriate to the organization.
- Preserve attribution. Ensure analysts can connect a query to a device, workload, or user without collecting unnecessary personal data.
- Prevent bypass. Control unauthorized port 53, DoT, DoH, and application-specific resolvers while allowing approved services.
- Integrate alerts. Send blocks and high-value DNS events to SIEM or SOAR and correlate them with endpoint and identity telemetry.
- Test failure modes. Simulate resolver outage, captive portals, VPN transitions, roaming, and remote work.
A phased rollout
Begin in observation mode with a representative pilot. Measure which resolvers clients use, how many queries would be blocked, where attribution is lost, and which applications depend on split DNS. Correct architecture and policy before enforcing broad blocks.
Next, enforce the approved resolver on managed endpoints and a small set of networks. Validate help-desk procedures, exception handling, and SIEM correlation. Expand by device class and location while monitoring latency, availability, false positives, and bypass attempts.
Finally, review the service as an ongoing control. Threat intelligence, retention needs, privacy expectations, device inventory, and browser behavior change. Re-test off-network clients and unmanaged DoH after major platform updates.
Common deployment mistakes
Turning on DoH in a browser and calling the project done. That protects one application path but may bypass internal resolution and leave other software on cleartext DNS.
Blocking port 853 while ignoring DoH. Dedicated DoT is easy to identify; unauthorized DoH can blend with ordinary HTTPS. Use endpoint and application policy, not only port rules.
Collecting every query forever. More data is not automatically better. Retain what security, operations, and compliance need, protect access, and delete according to policy.
Failing open without visibility. Availability may require fallback, but every fallback should be intentional, monitored, and tested. Otherwise the protection can disappear silently during exactly the outage an attacker wants to exploit.
Practical takeaways
Choose DoH when broad application support and HTTPS transport fit the environment. Choose DoT when a distinct, easily governed DNS channel is preferable. Choose protective DNS when you need filtering, enforcement, and incident visibility. For most managed organizations, the sound answer is an approved protective resolver reached over encrypted DNS, with clear privacy limits and controls against bypass.
Sources
- NIST SP 800-81 Rev. 3
- CISA Encrypted DNS Implementation Guidance
- RFC 8484: DNS over HTTPS
- RFC 7858: DNS over TLS
