Oblivious DNS over HTTPS (ODoH): Separating Client Identity from DNS Queries

Encrypting DNS hides queries from observers along the path, but ordinary encrypted DNS still leaves the resolver seeing both the DNS question and the network address of the client asking it.

Oblivious DNS over HTTPS, or ODoH, changes that relationship by inserting a proxy and encrypting the DNS message specifically for a separate target. The proxy knows where the client connection came from but can’t read the DNS question. The target can read the DNS question but receives it from the proxy rather than directly from the client.

ODoH splits information across three parties

RFC 9230 defines three roles:

• The Client creates the DNS query and chooses a proxy and target.
• The Proxy forwards an encrypted ODoH message between the client and target.
• The Target decrypts the DNS message and produces or obtains the DNS answer.

The target can resolve the query itself or forward it to another resolver.

The basic path looks like this:

Client  ->  ODoH Proxy  ->  ODoH Target  ->  DNS resolution
  ^              |               |
  |              |               +-- sees DNS plaintext, not client IP
  |              +-- sees client IP and target, not DNS plaintext
  +-- knows both the query and the selected path

The privacy property depends on the proxy and target remaining separate. RFC 9230 says they are expected to be non-colluding.

The DNS message is encrypted for the target before the proxy sees it

ODoH does more than put ordinary DoH behind a generic HTTP proxy.

Before the client sends the request to the proxy, it encrypts the DNS message using key material associated with the target. RFC 9230 uses Hybrid Public Key Encryption (HPKE) for this step. The proxy forwards the resulting encrypted ODoH message but doesn’t possess the target’s decryption key.

ODoH messages travel as HTTP POST requests. The client sends the binary ODoH query in the POST body, and the target returns the encrypted response in the corresponding HTTP response, both under the dedicated media type application/oblivious-dns-message. Because the encryption uses per-query ephemeral key material, RFC 9230 forbids caching ODoH requests and responses at the HTTP layer.

The target decrypts the query, processes it, and sends a response back through the same proxy, encrypted with keys derived from that query’s HPKE exchange rather than a second public-key operation. The proxy forwards that response to the client without needing to read the DNS payload.

Both the client-to-proxy and proxy-to-target HTTP exchanges use HTTPS. The inner ODoH encryption is still necessary because HTTPS to the proxy alone would terminate encryption at the proxy and expose the DNS message there.

This creates two protections at once. Transport encryption protects each HTTPS hop, while the ODoH message encryption prevents the intermediary proxy from learning the DNS contents it carries.

The proxy and target learn different facts

Under the ODoH design, the proxy and target each have an intentionally incomplete view.

The proxy sees:

• The client’s network connection and IP address
• The target selected by the client
• The timing and size of the encrypted ODoH messages

The proxy doesn’t receive the DNS question in plaintext.

The target sees:

• The plaintext DNS question and answer
• The proxy connection that delivered the request
• ODoH protocol information needed to process the exchange

By design, the proxy withholds client-identifying information from the target. RFC 9230 specifically prohibits proxies from forwarding client-identifying metadata such as a Forwarded HTTP header to the target. One caveat sits inside the DNS message itself. The target reads everything the client put in the query, so a client that includes identifying data such as an EDNS Client Subnet option hands the target a network prefix no proxy can strip.

That split is the core of ODoH. No single server in the intended proxy-target design independently receives both the client IP address and DNS message contents.

Separating knowledge is different from making a user anonymous

ODoH reduces a particular form of DNS linkability. It’s not a general-purpose anonymity network.

The client’s network still sees a connection to the ODoH proxy. The proxy still knows the client’s IP address. The target still knows the DNS names being queried. Other application traffic that follows DNS resolution may reveal the destination through separate protocols and connections.

RFC 9230 also leaves traffic-analysis mitigations outside its scope. Timing, message sizes, connection reuse, subsequent connections, and compromised infrastructure can all affect what an observer may infer beyond the protocol’s basic confidentiality guarantees.

This is why DNS privacy and anonymity need to be treated as different problems. ODoH deliberately separates two pieces of information that ordinary DoH places at the same resolver, but it doesn’t attempt to hide every observable fact about a client’s network activity.

Non-collusion is part of the trust model

ODoH works because the proxy and target are expected not to combine their views.

If the proxy shares client-identifying information with the target, the target can associate a query with the client. If the target and proxy are both compromised or cooperate to correlate their data, the intended separation can be lost.

This means ODoH distributes trust rather than removing it. No single service has to hold both halves of the information.

Operational details matter too. RFC 9230 recommends that proxies pool and reuse connections to targets across multiple clients. If a proxy creates a unique target connection for each client, the target may gain an additional correlation signal even without receiving the client’s actual IP address.

ODoH adds another dependency to DNS resolution

Direct DoH has a relatively simple encrypted path:

Client -> DoH resolver

ODoH intentionally adds another party:

Client -> ODoH proxy -> ODoH target

That extra hop creates operational consequences. The client needs configuration for both the proxy and target, as well as the target’s public key material. The proxy must be reachable and able to reach the target. The target must be available and able to resolve or forward the DNS query.

A failure at either service can prevent resolution through that ODoH path. How a client reacts to such failure is a deployment and implementation decision rather than a general DNS rule.

The additional intermediary also affects latency, connection management, abuse controls, and troubleshooting. RFC 9230 addresses connection reuse and rate limiting because the proxy is part of the live DNS delivery path, not just a conceptual privacy component.

ODoH builds on DoH rather than replacing DNS

ODoH still carries fully formed DNS messages. It doesn’t alter the DNS namespace, record types, caching rules at recursive resolvers, delegation, or authoritative resolution.

The change happens in how a privacy-sensitive query reaches the component that can read and resolve it. Ordinary DoH combines client identity and query contents at one endpoint. ODoH separates those observations across a proxy and a target.

That makes ODoH one example of a broader shift in modern DNS client behavior. The path a DNS question takes can now be chosen and protected by application-layer logic before the recursive resolver ever receives it.

Summary

Oblivious DNS over HTTPS introduces a proxy between the DNS client and an ODoH target, then encrypts the DNS message so the proxy can’t read it. The proxy can see the client connection, while the target can see the DNS query. The design depends on those parties remaining non-colluding and on deployments avoiding metadata that would reconnect the two views.

ODoH doesn’t make DNS disappear from the network. It makes one specific correlation harder: connecting a client’s IP address directly to the DNS questions seen by the resolver target.