Wiki · Concept · Last reviewed June 25, 2026

Oblivious DNS over HTTPS

Oblivious DNS over HTTPS, or ODoH, is an experimental protocol for sending encrypted DNS-over-HTTPS queries through a proxy so no single server sees both the client IP address and the DNS query contents.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: DNS, DoH, ODoH, privacy, agents, surveillance

Definition

Oblivious DNS over HTTPS is defined by RFC 9230, published in June 2022 as an Experimental RFC. The document describes a protocol that hides client IP addresses from DNS resolvers by proxying encrypted DNS-over-HTTPS messages. Its privacy goal is split knowledge: no one server entity should know both the client IP address and the content of DNS queries and answers.

ODoH builds on DNS over HTTPS, or DoH. RFC 8484 defines DoH as a way to send DNS queries and receive DNS responses over HTTPS, with each query-response pair mapped into an HTTP exchange. ODoH adds a proxy and target-resolver pattern to keep the resolver from directly seeing the client network address.

Mechanism

In the RFC 9230 model, the client encrypts a DNS message for an Oblivious Target, then sends it through an Oblivious Proxy. The proxy receives the client connection and forwards the encrypted payload, but it should not be able to read the DNS message. The target decrypts the query, resolves it, and returns an encrypted response back through the proxy.

The protocol uses the media type application/oblivious-dns-message and HTTP POST. The proxy URI template contains targethost and targetpath variables so the proxy can forward the encrypted message to the intended target endpoint. RFC 9230 uses Hybrid Public Key Encryption, specified in RFC 9180, for the public-key encryption layer.

Relationship to OHTTP

Oblivious HTTP, standardized later in RFC 9458, generalizes a similar relay-and-gateway pattern for encrypted HTTP messages. ODoH is narrower: it is specialized for DNS-over-HTTPS queries and is explicitly Experimental. OHTTP is Standards Track and describes a broader HTTP forwarding protocol.

That status difference matters. ODoH should not be described as a universal web privacy layer, a finished anonymity standard, or a replacement for every DNS privacy mechanism. It is a specific experimental design for separating DNS query content from client IP addresses through a one-hop application-layer proxy.

Agent Context

AI agents and browsers leak intent before a page loads. DNS lookups can reveal which domains a user, tool, or automated workflow is about to contact. For agent systems, those lookups may describe research targets, vendors, health sites, financial services, internal tools, or operational infrastructure. ODoH is relevant because it narrows what a resolver can learn from DNS traffic alone.

The protection is partial. The later HTTP request can still identify the account, device, region, browser, agent, or task. An enterprise proxy, local endpoint monitor, or application log may still retain enough evidence to reconstruct the activity. ODoH reduces one resolver-side view; it does not make agent browsing private by itself.

Governance Use

A governed ODoH deployment should record the client class, proxy operator, target resolver, targethost and targetpath policy, target public-key configuration, HPKE suite, DoH endpoint, error behavior, retention rule, and whether proxy and target are organizationally separate. It should also document whether queries are used for security filtering, measurement, abuse response, or personalization.

For AI systems, the record should connect DNS privacy to task policy. A coding agent resolving package registries, a browser agent visiting search results, and a workplace assistant contacting internal systems have different retention, audit, and disclosure needs. Resolver privacy should not erase accountability for high-risk actions.

Limits

ODoH is not a VPN, not Tor, not consent, and not a guarantee that a service cannot identify a person or agent. The proxy sees the client and target, even if it does not see the DNS payload. The target sees the DNS query and response, even if it should not see the client IP address. Collusion, small user populations, timing correlation, unusual query names, endpoint compromise, and identifying application traffic can weaken the privacy goal.

RFC 9230 also notes that the Oblivious Proxy is not a full HTTP proxy. That boundary should be preserved in policy language: ODoH is about proxied encrypted DNS-over-HTTPS messages, not all web traffic.

Source Discipline

Claims about ODoH status, roles, media type, proxy URI templates, target behavior, HPKE use, and privacy limits should cite RFC 9230. Claims about ordinary DoH should cite RFC 8484. Claims about HPKE should cite RFC 9180. Claims that compare ODoH with OHTTP should cite RFC 9458. Product deployment claims require operator documentation, not just protocol text.

Spiralist Reading

Spiralism reads ODoH as a lesson in split visibility. A resolver does not need a whole person to answer a name. A proxy does not need the name to forward a question. Separating those facts is a small refusal of default surveillance.

But split visibility is not the same as freedom from records. It moves trust into a route: client, proxy, target, key, policy, and logs. The ethical work is to keep the split real, keep the logs narrow, and keep users from mistaking one hidden layer for complete privacy.

Sources

Return to Wiki