DoH vs DoT: the DNS-privacy tradeoffs explained

Why plaintext DNS is a privacy gap worth closing

Every time a device resolves a domain name, it sends that query to a recursive resolver, and under the original DNS design, that query and its answer travel as plaintext — no encryption at all. This is a separate problem from the one DNSSEC solves: DNSSEC verifies that a DNS answer hasn’t been forged or tampered with, but it does nothing to hide the query from anyone watching the network (see our guide on what DNSSEC actually protects for that distinction in detail). Plaintext DNS means an ISP, a public Wi-Fi operator, or anyone positioned on the network path between you and your resolver can build a complete record of every domain you look up, even for sites you access entirely over HTTPS — the DNS lookup that precedes the HTTPS connection already gave away the destination. The IETF’s DPRIVE working group was formed specifically to address this gap, and DoT and DoH are its two resulting standards.

DoT: dedicated port, straightforward to identify

RFC 7858 defines DNS-over-TLS, which wraps standard DNS messages inside a TLS-encrypted connection on its own reserved port, 853. Architecturally, this is the simpler of the two approaches — it’s DNS wrapped in TLS, nothing more. The dedicated port is both DoT’s main practical strength and its main practical weakness depending on who you ask: a network operator who wants visibility into DNS traffic, or wants to enforce a specific resolver for content filtering or malware-domain blocking, can simply monitor or block port 853 without touching any other traffic. That makes DoT straightforward to deploy predictably on a managed network, but also straightforward for a restrictive network (or a censoring one) to block outright, forcing clients back to unencrypted DNS or no DNS at all.

DoH: blends in with web traffic, harder to selectively block

RFC 8484 defines DNS-over-HTTPS, which carries the same underlying DNS messages but frames them as HTTPS requests on port 443 — the same port essentially every website uses. This is the detail that matters most in practice: at the network level, a DoH query looks like ordinary HTTPS traffic to whatever resolver’s DoH endpoint it’s hitting. A network that wants to block DoH specifically, without blocking HTTPS broadly, generally has to resort to identifying and blocking specific known DoH endpoint addresses or using more invasive TLS inspection — neither of which is as simple as blocking one port. This is exactly why DoH has become the more broadly adopted option in consumer browsers (built into Firefox, Chrome, and Edge’s settings) and also why some enterprise and school network administrators specifically disable browser-level DoH, preferring to keep DNS on a visible, governable path through infrastructure they control.

The tradeoff in one sentence

DoT trades blockability for simplicity and clear separation from web traffic; DoH trades a harder-to-govern network boundary for resistance to selective blocking and broader out-of-the-box browser support. Neither is “more secure” than the other in a cryptographic sense — both use TLS underneath — the difference that actually matters is operational: who can see that DNS is happening at all, and who can enforce policy over it.

What neither protocol changes

Switching to DoH or DoT does not change who can see your queries in an absolute sense — it only changes the hop between your device and the resolver. The resolver itself still sees every query in full, so your actual privacy posture depends entirely on which resolver you point DoH/DoT at and that resolver’s own data retention and sharing practices. It also doesn’t change anything about DNS authenticity — a DoH or DoT connection to a resolver that itself returns tampered answers, or that doesn’t validate DNSSEC, offers encryption without the integrity guarantee DNSSEC separately provides.

How to check your own setup

Use AdminKit’s DNS resolver test tool to see which resolver your current connection is actually using and how it behaves, and DNS lookup to inspect specific records directly. Most large public DoH/DoT resolvers (Cloudflare, Google, Quad9) are deployed via anycast, so the specific server that actually answers a given query depends on where the request originates, not a single named machine. If you’re on a managed network (work, school) and DNS lookups behave differently than expected, that’s often a deliberate network policy around DoH/DoT rather than a misconfiguration — worth confirming with whoever manages that network before assuming something is broken.

Related checks

DNS privacy (DoH/DoT) and DNS authenticity (DNSSEC) are complementary, not competing, protections — see DNSSEC: what it actually protects for the authenticity half of this picture, and is my router’s DNS hijacked for a related DNS-trust scenario that encryption alone doesn’t fully prevent.