August 6, 2026·10 min read·Technical

The Layers of DNS Privacy: DoH, DoT, ODoH and What Each One Actually Hides

Each DNS privacy mechanism removes one specific observer. Knowing which one, and what remains visible afterwards, is the difference between a real threat model and a comfortable feeling.

By Guardino Team · Guardino Technologies

Every few years a new DNS privacy mechanism arrives and the discussion collapses into which one is best. That framing is not useful, because they are not competing answers to one question. Each removes a different observer, and after deploying all of them, some observers remain.

This walks through the chain, one observer at a time.

The starting position

Classic DNS, as specified in the 1980s, is plaintext UDP on port 53. When your device resolves a name:

The query goes to whichever resolver was configured, usually the one your provider handed over by DHCP.
It travels unencrypted and unauthenticated.
The resolver answers, possibly from cache, possibly by walking the delegation chain to an authoritative server.

There are three distinct problems in there, and it is worth separating them because different mechanisms address different ones:

Confidentiality on the path. Anyone between you and the resolver can read every query.
Integrity. Anyone on the path can also forge answers, because nothing is authenticated.
Trust in the resolver itself. It sees every query you make, correlated to your address.

DNSSEC: integrity, and only integrity

DNSSEC signs DNS records so a resolver can verify the answer came from the zone that owns the name and was not modified in transit.

What it fixes: forged answers, cache poisoning, an on-path attacker redirecting you.

What it does not fix: confidentiality, at all. A DNSSEC-validated query is still plaintext. Everyone on the path still reads it; they just cannot change it.

This is the most commonly misunderstood pairing. DNSSEC and encrypted transport are orthogonal, you can have either without the other, and you want both.

DNS-over-TLS: confidentiality on the path

DoT wraps DNS in TLS on a dedicated port. The queries become unreadable to anyone between you and the resolver, and the resolver's identity is authenticated by its certificate.

Removes: the passive observer on the network path. The café, the hotel, the transit provider, the person on the same wifi.

Does not remove: the resolver, which still sees everything.

Because it uses its own port, DoT is easy to identify on a network. A network operator can require it, block it, or observe that it is being used. That visibility is exactly what makes it attractive for a managed environment and unattractive for someone on a network that would prefer to inspect their traffic.

DoT is also what mobile platforms use for their system-wide encrypted DNS settings, which makes it the practical answer when you want one setting to apply to a whole device rather than to one browser.

DNS-over-HTTPS: the same confidentiality, harder to suppress

DoH carries DNS queries inside ordinary HTTPS requests on port 443.

Removes: the same observer DoT removes. The confidentiality guarantee is equivalent; this is not a stronger form of encryption.

Changes: the visibility of the fact that you are doing it. DoH traffic is difficult to distinguish from any other HTTPS traffic, so a network cannot easily block it without blocking a great deal else.

This is genuinely valuable for a user on a hostile network and genuinely inconvenient for a network administrator with a legitimate reason to enforce a policy. Both of those are true at once and the arguments about DoH are mostly people asserting one of them at people asserting the other.

One practical implication worth knowing: DoH is often configured per application rather than per device. A browser with DoH enabled protects the browser. It does nothing for the rest of the machine, which is still using whatever the system resolver was. If you want device-wide coverage, that is usually a system setting rather than a browser one.

Oblivious DNS-over-HTTPS: removing the resolver from the equation

Everything above leaves one observer untouched: the resolver you chose. It sees every query, tied to your address.

ODoH addresses this by splitting the knowledge between two parties. The client encrypts its query to the target resolver, then sends it through a relay. The relay sees who you are but cannot read the query, because it is encrypted to the target. The target can read the query but sees only the relay's address, so it does not know who asked.

Removes: the resolver's ability to correlate queries with a person, provided the relay and the target do not collude.

Requires: that they genuinely do not, which in practice means separate organisations with separate interests. The security property is only as real as that separation.

ODoH is the most interesting mechanism in this list and the least deployed. Support exists but is not something most people can simply switch on, and the ecosystem of independent relays is thin. Worth knowing about, worth watching, not yet a default answer.

What remains visible after all of this

Suppose you have deployed encrypted transport, validated DNSSEC, and are using an oblivious arrangement. Your queries are confidential, authenticated, and unlinkable. Your internet provider learns nothing from your DNS.

They still learn a great deal.

The destination IP address. After the lookup, your device connects to an address. That connection is visible. For a site on dedicated hosting, the address identifies the site as reliably as the name would have. The mitigation, in practice, is shared hosting and large CDNs, where one address serves thousands of sites. That is a mitigation by accident rather than by design, and it does not apply to smaller destinations.

The TLS handshake. Historically the hostname travelled in the clear in the Server Name Indication field of the client hello, which meant the name was visible even with encrypted DNS. Encrypted Client Hello is designed to close this, and deployment is progressing rather than complete. Until it is universal, this is often the widest remaining channel.

Traffic analysis. Volumes, timings and packet sizes carry information. This is a research-grade attack rather than something a typical observer performs, but it is not nothing.

Everything above the network. The site you connected to knows exactly who you are, and so do its analytics and advertising partners. No DNS mechanism touches this, and for most people it is the larger exposure by a wide margin.

The point of listing these is not to argue that encrypted DNS is pointless. It is that a threat model with one item in it is not a threat model. Encrypting DNS closes a real channel cheaply. It does not make you unobservable, and a mental model that assumes it does will lead to worse decisions elsewhere.

Where filtering fits

A filtering resolver is a separate axis from all of the above and is often conflated with it.

Filtering is a policy decision applied at the moment of the lookup: this domain is on a list, so no answer is returned. It composes with every mechanism here. An encrypted, DNSSEC-validated query to a filtering resolver is entirely coherent.

What it does mean is that you have chosen a specific resolver on purpose, which brings the resolver-trust question back to the front. If the point of filtering is that a service applies your policy, that service necessarily sees the queries it is applying the policy to. The relevant question is therefore not whether it sees them but what it keeps, for how long, and whether you had a say.

That is a question about retention practice rather than about cryptography, and it is the one most worth asking after the transport is encrypted.

A practical ordering

If you are deciding what to actually do, in descending order of benefit per unit of effort:

Turn on encrypted DNS device-wide, DoT or DoH, rather than in one browser. This closes the path observer for everything on the machine.
Choose the resolver deliberately and read what it says about retention. After step one, this is the whole remaining DNS question.
Enable Encrypted Client Hello where your browser supports it, since SNI is often the widest remaining leak.
Treat DNSSEC validation as a bonus your resolver either does or does not do. It is worth preferring, and it is not the confidentiality control.
Watch ODoH. When independent relays become ordinary, it is the meaningful next step.

And then stop thinking about DNS, because the larger exposures are elsewhere and DNS has a habit of absorbing attention out of proportion to its share of the problem.

Frequently asked questions

If I use DNS-over-HTTPS, can my internet provider still tell which sites I visit?+

Often yes, through other channels. DoH removes their view of the lookup itself, but the connection that follows still goes to an IP address they can see, and for a site on dedicated hosting that address maps to one name. The TLS handshake historically carried the hostname in the clear in the Server Name Indication field, which Encrypted Client Hello is designed to fix but which is not universally deployed. So DoH is necessary and not sufficient: it closes one channel out of three, and the other two need their own answers.

What is the practical difference between DoH and DoT?+

Both encrypt the same queries to the same kind of resolver, and the confidentiality they provide is equivalent. The difference is where they sit. DoT uses a dedicated port, which makes it clean to reason about and trivial for a network to block or to require. DoH rides inside ordinary HTTPS traffic, which makes it much harder to block and also much harder for a network administrator to see or control. Which of those is a feature depends on whether you are the user or the administrator.

Does Oblivious DNS actually remove the need to trust a resolver?+

It removes the need to trust any single party with both halves of the information. A relay learns who you are but not what you asked; the target resolver learns what was asked but not who asked. The remaining assumption is that the relay and the target do not collude, which is why they should be operated by separate organisations with no incentive to combine their data. That is a meaningfully weaker assumption than trusting one resolver with everything, and it is not the same as trusting nobody.

Which of these should I actually deploy?+

Encrypted DNS of some kind, always, because the alternative is plaintext queries readable by anyone on the path and there is no longer a good reason to accept that. Choose DoT if you control the network and want it visible and enforceable, DoH if you want it to survive networks that would rather you did not. Then spend your remaining attention on the resolver's retention practice, which after encryption is the part that determines what is actually kept about you.

Ready

Reclaim your attention.

Set up Guardino in two minutes. Your first 300K queries are on us.

Start your protection→

How to Audit a DNS Provider's Privacy Claims: A Checklist

Every DNS provider says they respect your privacy. Here are the eleven questions that distinguish the ones who have thought about it, and what a bad answer to each one looks like.

DoH vs DoT vs Classic DNS: What Your Router Should Use in 2026

Classic DNS is a postcard. DoT is a sealed envelope. DoH is a sealed envelope hidden inside regular mail. Here's which one to use, and where.