Skip to content
Tech News
← Back to articles

Show HN: Running the second public ODoH relay

read original get ODoH Relay Server Kit → more articles
Why This Matters

The deployment of the second public ODoH relay marks a significant step toward enhancing DNS privacy by allowing users to query DNS anonymously without relying on accounts or platform lock-in. This development empowers consumers and the tech industry with more privacy-preserving options, reducing the risk of data exposure and tracking across the internet.

Key Takeaways

Anonymous DNS without an account: shipping ODoH client + relay in one Rust binary

If you run Pi-hole, AdGuard Home, or any forwarding resolver, every one of your queries goes through one operator who sees both your IP address and the question. If you switch to a recursive resolver like Unbound, your IP gets exposed to every authoritative nameserver instead - .com learns you exist, google.com learns you exist, and so does every CDN edge in the chain. DoH and DoT encrypt the transport; they don’t change who learns what.

Apple’s iCloud Private Relay solved this for Apple users by splitting the path: an ingress proxy sees your IP but not the request, an egress proxy sees the request but not your IP. DNS gets anonymized system-wide, but only with iCloud+ ($0.99/mo), only on iOS/macOS, and only through Apple-curated egress partners. NextDNS, Cloudflare for Families, Quad9 - all the privacy-focused DNS services - require accounts, telemetry, or both. The self-hosted audience effectively had no anonymous-DNS option without an account or a platform lock-in.

Hops that see {your IP, your question} {1, 1} → {disjoint} relay sees IP, target sees question Crypto primitives all audited odoh-rs (HPKE) · rustls (TLS) — zero custom Account required none single binary, MIT, default config works

ODoH (RFC 9230, “Oblivious DNS over HTTPS”) is the IETF protocol that does this for DNS. Numa v0.14 ships a client, a relay, and a public deployment in one binary. This post is what it does, what it doesn’t fix, and what it took to deploy the second public relay in the ecosystem.

How it works

INDEPENDENT OPERATORS - MUST NOT COLLUDE [encrypted ████] A example.com? 93.184.216.34 [encrypted ████] YOU NUMA RELAY CLOUDFLARE AUTHORITATIVE YouEncrypts the query under target’s HPKE pubkey. Includes a symmetric key for the response. Numa relaySees your IP. Sees only ciphertext, in both directions. Cloudflare targetDecrypts the question. Sees no IP - just relay’s. AuthoritativeStandard DNS recursion. Cloudflare’s job, not yours. ReturnCloudflare encrypts the answer with the symmetric key you supplied and sends it back along the same path. Relay still sees only ciphertext. Same privacy property, opposite direction.

Encryption uses HPKE (RFC 9180) - the same primitive as TLS Encrypted ClientHello. Cloudflare publishes odoh-rs for the seal/open operations and I used it. Numa’s hand-rolling principle is no DNS libraries; HPKE is a different thing, and hand-rolling crypto is the kind of decision where every hour of “I want full control” buys ten of audit anxiety.

What it took to build

ODoH client mode plugs into Numa’s existing forwarding pipeline as a fourth transport (alongside UDP, DoH, DoT). The relay is a separate mode ( numa relay [PORT] ) - same binary, different entry point, only POST /relay and GET /health exposed. Two things in the relay needed more attention than expected:

... continue reading