ODoH: Breaking the Link Between DNS Queries and Client IPs
Cloudflare, in collaboration with Apple, Fastly, PCCW, SURF, and Equinix, today announced support for Oblivious DNS over HTTPS (ODoH), a proposed IETF standard that adds a layer of public key encryption and a network proxy between clients and DNS resolvers such as 1.1.1.1. With the combination of these two elements, no single entity in the resolution path can observe both the client's IP address and the DNS query at the same time. The company has also open sourced its Go and Rust implementations of the protocol.
Why DNS needs another layer of privacy
Standard DNS transmits queries in cleartext, allowing anyone on the network path between a device and its resolver to see both the requested hostname and the client's IP address. DNS over HTTPS (DoH) and DNS over TLS (DoT) address this by encrypting traffic between client and resolver, yet that still leaves a structural gap: the resolver itself retains full visibility into which client is asking for what.
The small set of public DoH/DoT providers, which includes Cloudflare's 1.1.1.1, are protected by privacy policies and audits. But trust in those policies, or in a resolver operator's handling of query data, remains a barrier for some users. ODoH is an attempt to replace that trust requirement with technical guarantees.
How the ODoH architecture separates concerns
ODoH adds two components between the client and the recursive resolver: end-to-end encryption of the DNS message itself and a proxy server that is completely disjoint from the target resolver.
There are three participants on the ODoH path:
- The target decrypts queries forwarded by the proxy, produces a response, and encrypts the response back to the client. The target may or may not be the recursive resolver itself; for performance, Cloudflare expects they will often be the same. In this case, 1.1.1.1 now runs as both.
- The proxy simply forwards encrypted messages between the client and target. Launch proxy partners include PCCW, SURF, and Equinix.
- The client sends and receives normal DNS over HTTPS but encrypts its queries for the target before transmitting them through the proxy.
Those roles yield three guarantees:
- The target sees only the query and the proxy's IP address, never the client's address.
- The proxy cannot read, identify, or modify either the client's query or the target's response.
- Only the intended target can decrypt the query and craft a response.
This architecture relies on non-collusion between proxy and target. An attacker succeeds only by compromising both endpoints. Clients retain full control over which proxy and target they use, and can change either at any time.
Performance profile: ODoH vs. DoH vs. Tor
Cloudflare's measurements, presented in an open-access technical report, set out to isolate the added encryption and proxying costs from the TCP/TLS connection setup that regular DoH incurs anyway. To do so, the tests primed each connection once and reused it, and evaluated 10,000 randomly selected domains from the Tranco million dataset.
The initial results, spanning cities across the USA, Canada, and Brazil, put ODoH's performance between standard DoH and DoH over Tor:
- The extra end-to-end encryption beyond proxied DoH consistently added less than 1 ms at the 99th percentile.
- 50% of ODoH queries resolved within 228 ms.
- Comparable DoH queries resolved within 146 ms; over Tor, query time was at least double ODoH's.
- Half of the ODoH curves showed a time difference never exceeding 100 ms versus standard DoH.
Selecting proxies and targets based on raw latency carries a counterintuitive twist: choosing the lowest-latency proxy actually produced worse performance. Half of all ODoH query/response times were virtually indistinguishable regardless of which proxy or target was selected. Cloudflare notes the measurements focused on North America and says global behavior remains an open question.
Encryption and message flow
The "oblivious" property comes from additional end-to-end encryption layered on top of the HTTPS sessions. Proxying DoH requires the proxy to terminate one TLS connection from the client and open a new TLS connection to the target; without an extra encryption step, DNS messages would be visible in plaintext between those two connection hops.
ODoH closes that gap using HPKE (Hybrid Public Key Encryption). Clients begin by fetching the target's public key, which is published as a DNSSEC-protected HTTPS resource record. A request for that key is made only when the record's TTL expires, just as with an A or AAAA record.
The client encrypts a query using that public key and sends it to the proxy over an HTTPS connection. The proxy forwards it to the target, which decrypts the query, forwards it upstream to a recursive resolver, and encrypts the response using symmetric keying material embedded in the client's original encrypted query. The target's response travels back through the proxy to the client. To the proxy, even the decrypted DNS message amounts to an encrypted garble it cannot parse.
Experimentation and implementation status
Cloudflare has made its interoperable ODoH implementations available in Rust (odoh-rs) and Go (odoh-go), plus test clients in both languages (odoh-client-rs and odoh-client-go). The 1.1.1.1 resolver is already able to receive queries via ODoH. Cloudflare says it is working to integrate ODoH into existing stub resolvers such as cloudflared and is encouraging more operators to run additional proxies and targets.
