Show HN: Running the second public ODoH relay
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.
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.
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.
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:
SSRF-hardened hostname validator. The relay opens an outbound connection to a target named in the request URL. Without validation that’s textbook SSRF - a malicious client could ask it to “forward” to 169.254.169.254 and exfiltrate cloud metadata. The validator is regex-strict (RFC 1035 ASCII labels, no IDN, no IP literals, no non-443 port).