Anonymous DNS with ODoH: Breaking the Link Between IP and Query

For users of Pi-hole, AdGuard Home, or standard forwarding resolvers, the privacy trade-off is stark: a single operator sees both your IP address and every site you visit. While switching to a recursive resolver like Unbound removes the middleman, it exposes your IP directly to authoritative nameservers—meaning .com or google.com knows exactly who is asking. Even DNS over HTTPS (DoH) and DNS over TLS (DoT) only encrypt the transport; they do not change who possesses the data.

To solve this, the IETF introduced Oblivious DNS over HTTPS (ODoH) (RFC 9230). The goal is to ensure that no single entity in the DNS chain knows both the requester's identity (IP address) and the request itself. The Numa project has recently implemented this by shipping an ODoH client and relay in a single Rust binary, while also deploying one of the few remaining public relays in the ecosystem.

How ODoH Works: The Split-Path Architecture

ODoH achieves anonymity by splitting the DNS resolution path between two distinct entities: a Relay and a Target.

1. The Client: The user encrypts their DNS query using the Target's public key (HPKE). This encryption includes a symmetric key for the response.
2. The Relay: The query is sent to the relay. The relay sees the client's IP address but cannot decrypt the query. It simply forwards the ciphertext to the target.
3. The Target: The target (e.g., Cloudflare) decrypts the query. It sees the request but only sees the IP address of the relay, not the original client.
4. The Return: The target encrypts the answer with the symmetric key and sends it back through the relay to the client. The relay still sees only ciphertext.

By ensuring the Relay and Target are operated by different organizations, the link between the user's IP and their DNS query is cryptographically broken.

Engineering the Numa Relay

Implementing a public relay requires more than just forwarding packets; it requires strict security boundaries to prevent the infrastructure from being abused.

SSRF Hardening

Because the relay opens outbound connections to targets specified in the request, it is a prime target for Server-Side Request Forgery (SSRF). A malicious client could attempt to force the relay to query internal cloud metadata services (like 169.254.169.254). To mitigate this, Numa employs a regex-strict hostname validator that permits only RFC 1035 ASCII labels, forbidding IP literals, IDN, and non-standard ports.

The Same-Operator Check

ODoH is "security theater" if the relay and target are owned by the same organization, as they could simply correlate logs to re-identify the user. Numa implements an eTLD+1 check to reject configurations where the relay and target share the same domain owner by default.

Critical Limitations and Trade-offs

While ODoH significantly improves privacy, it is not a silver bullet. Several operational and theoretical risks remain:

• Target Trust: ODoH moves trust rather than eliminating it. The target still sees the question; the protection is operational (the target doesn't know who you are), not cryptographic.
• Traffic Analysis: Small relays are vulnerable to timing attacks. If only one user is active on a relay, a target can correlate the arrival of a query with the client's activity. Anonymity scales with the volume of users and the addition of padding traffic.
• Centralized Key Distribution: Currently, clients fetch the target's HPKE configuration via standard HTTPS. This relies on the WebPKI system; if the certificate authority system is compromised, the ODoH configuration could be spoofed.
• Egress Leaks: ODoH only protects the client-to-target hop. If the target is a recursive resolver, the subsequent queries to root and TLD servers are typically plaintext UDP/TCP.

The State of the ODoH Ecosystem

The public ODoH infrastructure is currently sparse. For a long time, the ecosystem relied almost entirely on a single public relay (odoh-relay.edgecompute.app). By deploying odoh-relay.numa.rs, Numa adds a second independent operator to the mix, increasing the diversity and resilience of the network.

Community discussion highlights the ongoing debate between managed anonymity and self-hosting. Some users argue that running a local Unbound instance with a custom cache-warming strategy is superior for those who want total control. Others suggest that routing DNS over Tor (DoHoT) provides a stronger threat model, albeit with higher latency.

Getting Started with Numa

For those looking to implement anonymous DNS, Numa provides a turnkey solution. By installing the binary and setting mode = "odoh" in the configuration, queries are routed through two independent organizations. For Docker users, preconfigured compose recipes are available to deploy either the client or a self-hosted relay to help grow the anonymity set of the public ecosystem.