DoH vs DoT: where each encrypted DNS transport leaks

The wrong question is "which one is more private?"

Both DNS over TLS and DNS over HTTPS encrypt the query on the wire. Both stop the old, boring failure mode where anyone on path can read or tamper with plaintext DNS. If that is all you wanted to know, the article could end here.

But privacy engineering gets worse when you stop at the first true sentence.

The real difference between DoT and DoH is not whether they encrypt. It is where they sit in the stack, what they look like to the network, and how easily they bypass the DNS policy you thought you had. That is where the leaks are.

The fast comparison

That table is the useful answer, but it needs explanation.

What DoT hides, and what it still exposes

RFC 7858 exists for a very simple reason: plaintext DNS is trivial to observe and trivial to tamper with. Wrapping DNS in TLS removes those easy on-path attacks.

Operationally, DoT is clean:

• dedicated port 853
• one obvious protocol purpose
• connection reuse encouraged
• clear strict-versus-opportunistic policy language in RFC 8310

That clarity is part of the appeal. A whole-device resolver using DoT is usually easier to reason about than a browser quietly doing its own DNS thing over HTTPS.

But DoT does not disappear into the background. It is still visible as encrypted DNS traffic. An observer may not know the names you asked for, but they can often tell that you are speaking DoT because the destination and port are obvious. That matters on networks where "DNS is encrypted" is itself the interesting signal.

So DoT hides content well, but it does not hide intent especially well.

If your threat model is "stop ISP or coffee-shop snooping," that is usually fine. If your threat model is "do not make my DNS behavior easy to classify," DoT is much less magical.

What DoH hides, and what it still exposes

RFC 8484 sends DNS over HTTP, usually HTTPS on port 443. That is the whole trick.

As Cloudflare's DoH documentation puts it, DoH can camouflage DNS inside normal web traffic. That is the main operational advantage. To the network, your resolver traffic looks much more like ordinary HTTPS.

That camouflage buys you something real. It also changes the failure modes.

Because DoH rides inside HTTP, it inherits HTTP's privacy properties and HTTP's privacy mess:

• the resolver still sees every name you ask it to resolve
• the client IP is still a correlation point
• the browser or app can choose its own resolver path
• you may need plaintext DNS or some existing trust path just to bootstrap the DoH endpoint in the first place

That bootstrapping problem is not theoretical. RFC 8484 explicitly calls it out. Before you can ask a DoH server a question, you have to know how to reach the DoH server.

And then there is the policy problem.

Browser-integrated DoH is often where privacy and manageability start fighting. Firefox is unusually candid about it in its support docs: DoH can bypass local resolvers, which means it can also bypass local filtering, enterprise controls, and DNS policy you intentionally configured on the host or VPN. Mozilla also documents that Firefox's chosen DoH resolver can take priority over the resolver configured by the VPN extension itself. See Firefox DNS over HTTPS and Mozilla's VPN extension note.

This is the most important DoH leak for operators. It is not a packet leak. It is a control leak.

Where each one leaks in practice

Here is the operator version:

• DoT leaks what kind of traffic this is.
• DoH leaks who is really making DNS decisions.

DoT on port 853 is obvious. If a network classifies traffic by port and protocol shape, DoT is easier to spot than DoH. That does not mean DoT is bad. It means you should stop pretending it is invisible.

DoH on port 443 is much harder to classify from the outside, but it is also much easier to smuggle into places where your OS, router, VPN, or local resolver policy is supposed to matter. A browser that quietly decides "I know a better resolver than the one the machine is using" is a privacy feature in one threat model and a configuration failure in another.

This is why network OPSEC is never just "turn on encryption." The whole stack has to agree on where resolution happens.

And neither protocol fixes the oldest trust problem: the recursive resolver itself still sees the names you ask it for. Encrypted DNS narrows who can watch. It does not eliminate watchability.

Fallback is where threat models go to die

The most dangerous encrypted-DNS setting is often not the transport choice. It is the quiet fallback behavior.

RFC 8310 is useful here because it distinguishes Strict Privacy from Opportunistic Privacy. That sounds abstract, but the operator lesson is simple:

• If failure means "do not resolve," you have a clear security story.
• If failure means "silently use plaintext DNS anyway," you have a convenience story wearing a privacy hat.

That distinction matters more than the DoH-versus-DoT debate in a lot of real systems.

Firefox's "Default Protection" mode is instructive because Mozilla documents that it disables DoH in certain conditions, including VPN, parental-control, or enterprise-policy cases. That is a sane product choice, but it also proves the point: transport policy is contextual, and the browser is making decisions on your behalf. See Firefox DNS over HTTPS settings behavior.

If you want a threat model you can explain in one sentence, silent fallback is usually the enemy.

Testing them directly

Do not trust a checkbox. Ask the resolver directly.

For DoT:

openssl s_client -connect 1.1.1.1:853
kdig +tls @1.1.1.1 example.com

For DoH:

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Those are not end-to-end privacy tests. They are transport sanity checks. Useful, but incomplete.

The full audit is closer to this:

1. Confirm which resolver the OS thinks it is using.
2. Confirm which resolver the browser thinks it is using.
3. Confirm what the VPN is trying to enforce.
4. Re-test after Wi-Fi changes, browser updates, and VPN changes.

That is also why this article pairs with /blog/pihole-doh-home-network and /blog/ipv6-leak-prevention. DNS leaks rarely arrive alone.

So which one should you use?

My opinion is boring and useful.

If you want whole-device control you can audit, prefer DoT or an OS-level encrypted DNS path that behaves like DoT in practice. The protocol is explicit, the policy boundary is cleaner, and you are less likely to let every browser invent its own resolver politics.

If you want browser-scoped privacy or you are on a network where port 853 is conspicuous or blocked, DoH is usually the practical answer. That is its real strength. Not "better privacy in the abstract," but "harder to distinguish from normal HTTPS traffic."

If you are self-hosting or hardening a tunnel stack, the more important question is whether your DNS story is coherent across the host, browser, and VPN. An elegant DoH setup that bypasses the resolver policy you intentionally built is not an upgrade. It is drift.

The bad decision pattern is thinking these are mostly interchangeable because both have the word "encrypted" in the title.

They are not.

DoT is easier to govern and easier to classify. DoH is harder to classify and easier to let slip past local policy. Pick the failure mode you actually understand, then verify the stack is behaving the way you think it is. That is more valuable than winning an argument about which acronym is more private.

If your real goal is a simpler whole-device setup, /blog/self-hosted-wireguard-2026 is usually the better next step than endlessly bikeshedding resolver transports.