Oblivious DoH: Splitting Who You Are From What You Ask

Encrypting your DNS queries solved one privacy problem and created another. With plain DNS, every device on your network path could read the names of every site you visited. DNS over HTTPS fixed that — but it handed the entire stream of your browsing intentions to whichever resolver you chose, neatly tied to your IP address. You traded a crowd of eavesdroppers for one very well-positioned one. Oblivious DoH is the attempt to close that last gap.

The core insight is structural, not cryptographic: a DNS resolver only becomes a privacy threat when it can see both who is asking and what they're asking. Separate those two facts across two non-colluding parties, and the resolver that answers your query never learns it was you, while the party that knows it was you never learns the query.

What plain DoH still leaks

As covered in our piece on DNS over HTTPS privacy, DoH encrypts the query between you and the resolver, hiding it from your ISP, your coffee-shop Wi-Fi, and anyone else on the path. That is a genuine improvement. But the resolver itself sits at the other end of that tunnel, and it sees the cleartext query alongside the source IP address of the connection.

For a large public resolver, that is an extraordinarily rich data stream: a timestamped log of (roughly) every domain every user intends to contact. Even resolvers with sincere no-logging policies are a single subpoena, breach, or policy change away from becoming a surveillance asset. DNS leaks can make it worse, but even a perfectly configured DoH setup concentrates trust in one operator.

How Oblivious DoH works

Oblivious DoH, standardized as RFC 9230 in 2022, inserts a third party — an oblivious proxy — between you and the target resolver, and changes what each one can see.

The client does not encrypt its query to the proxy. Instead it encrypts the query to the target resolver's public key, using Hybrid Public Key Encryption (HPKE), and then sends that sealed blob through the proxy. The proxy forwards the encrypted query to the target and relays the encrypted answer back. The result is a careful division of knowledge:

No single party holds both halves. The proxy knows you but not what you asked; the resolver knows what was asked but not by whom. The privacy guarantee rests on one assumption stated bluntly in the design: the proxy and the target must not collude. If they share notes, the protection collapses to ordinary DoH.

The HPKE foundation

The encryption that makes this work is HPKE (RFC 9180), a modern standard for sealing a message to a recipient's public key. The client fetches the target resolver's published key, derives a fresh shared secret, and encrypts the query so that only that target can open it — even though the message physically passes through the proxy. HPKE is the same primitive underpinning Encrypted Client Hello and the broader Oblivious HTTP framework (RFC 9458), which generalizes this "split the observer in two" pattern beyond DNS to arbitrary HTTP requests.

"Oblivious systems don't ask you to trust one party more. They engineer the situation so that no single party is in a position to betray you."

How it compares to other DNS privacy options

Oblivious DoH is not a replacement for everything in the encrypted DNS landscape — it solves a specific problem. DNSSEC, for example, authenticates that an answer wasn't tampered with but does nothing for confidentiality. DoH and DoT provide confidentiality against the network but not the resolver. ODoH adds resolver-level unlinkability on top of DoH's confidentiality. They sit at different layers and are best understood as complementary rather than competing.

The trade-off is real: routing through a proxy adds a network hop and therefore latency, and the ecosystem of available oblivious proxies and targets is still smaller than the field of plain DoH resolvers. Apple's iCloud Private Relay applies the same dual-hop, split-knowledge principle to web traffic, which has done more than any standards document to make the architecture mainstream.

Should you use it?

For a typical user, well-configured DoH from a resolver you've deliberately chosen is already a large step up from your ISP's default. Oblivious DoH matters most when you cannot or will not extend that trust to any single resolver — when the threat includes the resolver operator itself, whether through logging, compromise, or legal compulsion. It is a precise answer to a precise worry: not "can someone on my network see my lookups," but "can the one party answering my lookups build a profile of me." If that question keeps you up at night, splitting the observer is the cleanest fix the standards bodies have produced.