DNS Resolver Privacy: DoH and DoT Deployment Tradeoffs

DNS over HTTPS (DoH) and DNS over TLS (DoT) protect DNS traffic from passive observation between a client and resolver, but they move trust rather than remove it. The chosen resolver still sees queries and can influence answers.

Why this deserves a deliberate process

A deployment must preserve internal names, parental or enterprise controls, incident response, captive portal behavior, and failure recovery without silently sending private queries to an unintended public service.

A practical workflow

1. Define the threat model. State whether the goal is protection on local Wi-Fi, ISP privacy, enterprise integrity, or policy consistency.
2. Choose resolver governance. Review operator privacy terms, retention, jurisdiction, DNSSEC validation, filtering, availability, and contractual controls.
3. Design discovery and bootstrap. Document how clients learn the encrypted endpoint, validate its certificate, and resolve its name without circular dependency.
4. Preserve split DNS. Route internal zones to authorized resolvers and test VPN, roaming, captive portal, and multi-network transitions.
5. Control fallback. Decide whether failure should block, use another encrypted resolver, or permit ordinary DNS; make the choice visible in telemetry.

Work through a realistic case

A company enables managed DoH on laptops. Internal zones remain on corporate resolvers through policy, while public names use a contracted privacy resolver. Tests cover office, home, hotel portal, VPN, and resolver outage. Ordinary DNS fallback is disabled for managed profiles but an emergency support procedure exists.

Evidence and measurements

Use a compact evidence set rather than a vanity dashboard. Track encrypted-query share, fallback events, resolution latency, internal-name failures, resolver outages, policy bypass attempts.

Explain the privacy boundary honestly

DoH is specified in RFC 8484 and DoT in RFC 7858. Both encrypt the client-to-resolver transport when correctly implemented. Neither hides destination IP traffic from the network nor prevents a resolver from logging queries. DNSSEC, where validated, addresses authenticity of DNS data; it is not transport encryption.

A managed deployment should test browser, operating-system, and application resolver settings together. One application may use a built-in resolver while another uses the system policy. Record which paths are controlled and which are intentionally excluded. Avoid claiming that one device-wide toggle covers every application.

During troubleshooting, compare an authorized public name and an internal name across network states. Capture resolver selection, response code, latency, certificate error, and fallback—not private browsing history. If a hotel portal requires temporary ordinary DNS, define the permitted scope and restore encrypted policy afterward. The support procedure should not leave a permanent bypass behind.

Common mistakes

• Calling encryption anonymity: The resolver and destinations can still observe important metadata.
• Ignoring browser settings: Application-level DoH may bypass operating-system policy.
• Breaking captive portals: Users need a controlled way to complete network access.
• No outage route: Centralizing DNS creates a new dependency.

Review checklist

• Evidence is available for the resolver trust review, with a named owner and review date.
• Evidence is available for client and application policy, with a named owner and review date.
• Evidence is available for split-horizon tests, with a named owner and review date.
• Evidence is available for fallback behavior, with a named owner and review date.
• Evidence is available for outage and support drills, with a named owner and review date.

Put it into routine operations

Compare resolver behavior with authorized test domains and use the Duck Cloud DNS tool only for public records, since it cannot see private split-horizon zones.

Related Duck Cloud tools

Inspect public records with DNS Lookup and review DNSSEC Validation Failures.

Troubleshoot without collecting browsing history

Start with a small set of authorized diagnostic names. Include a public name with a known answer, an internal name, a deliberately nonexistent name, and a name whose response changes under the intended filtering policy. Record the configured resolver, transport, response code, certificate result, and elapsed time. This is enough to identify many policy failures without retaining the user's full query stream.

Test certificate validation and time settings when encrypted resolution fails. A wrong device clock or inaccessible bootstrap endpoint can look like a DNS outage. Do not bypass TLS verification to make the test pass. Confirm the resolver's official endpoint and the system's trust configuration through supported tools.

For VPN transitions, test whether internal names leak to public resolvers before the tunnel becomes ready and after it disconnects. A split-horizon policy must specify behavior during transition, not only steady state. Consider whether the application retries with its own resolver after the system route fails.

Finally, exercise a resolver outage. Measure how quickly clients detect failure, which alternate endpoint they use, and whether answers differ because filtering or DNSSEC behavior changed. Explain any fallback in the support documentation. An encrypted primary with an unnoticed plaintext fallback can fail the privacy objective precisely when the network is unreliable. The correct policy depends on the required balance between confidentiality and service availability.

Conclusion

Encrypted DNS is useful when resolver trust, fallback, and internal routing are designed as deliberately as encryption itself.