Show HN: Running the second public ODoH relay (numa.rs)
Every privacy-focused DNS service requires an account: NextDNS, Cloudflare for Families, Apple's iCloud Private Relay (paid, iOS-only). The protocol that doesn’t require one - ODoH - had basically one well-known public relay operator (Frank Denis on Fastly Compute, default in dnscrypt-proxy). I built a second one and the client to talk to it.
14 comments
[ 3.3 ms ] story [ 35.6 ms ] thread``` cargo install numa
# set mode = "odoh" in numa.toml ```
Repo: https://github.com/razvandimescu/numa
And, funnily enough, they want data from users who are looking for "privacy"
Also, ODoH claims it will hide the client's IP address. ECH, even it were adopted by CDNs and websites, cf. being "supported" by a browser,^2 will not hide the client's IP address
1. Silicon Valley has this bizarre narrative where ISPs are the "bad guys" when it's Silicon Valley who created the online surveillance dystopia we are living in. Truthfully it's a competition over who can collect more data, conduct more surveillance and perform more ad services: Silicon Valley or ISPs. Silicon Valley is generally 100% focused on this as a "business model", cf. selling internet access, they have captured the market and they pose a much greater threat to the user seeking "privacy"
2. Where the browser vendor is Silicon Valley and data collection, surveillance and online advertising services is the "business model"
NB. Third party recursive DNS service has other uses besides "privacy", e.g., avoiding censorship
Me personally, I will stick with running my own DoH servers and thus I need not run any turtles (layer 4 proxies) in the middle of my already encrypted connections. Anyone running Unbound DNS can enable DoH if Unbound was built including '--with-libnghttp2' which the Alpine Linux version has. At the moment my browser is talking to Unbound over DoH on my local network so I get the advantages of ECN but I can easily switch it to any server where I have installed Unbound. Ultimately DNS at some point will be unencrypted UDP port 53 so I would rather it be me that determines where that happens so I can optimize my own cache and pre-cache cron jobs to mask my DNS behavior, but that's just me. Others can do whatever they want, as they should. The people that operate my ISP are bigger deviants than I and they know that I know that they know that I know this.
Oh and as a funny side note, I can warm up cache on entirely unrelated nodes and then transfer the cache export to any node and keep it valid on that node as long as I wish making the vast majority of my DNS requests respond in less than 700 nanoseconds not that I am in any hurry.
I can then bring those cache dumps in from any node to my home network making DNS resolution entirely invisible. Automation is only limited to ones imagination. Or AI's imagination. I personally find it beneficial to listen to Pure Imagination from Willy Wonka & The Chocolate Factory (1971) RIP Gene Wilderspeed (over tor) is not a concern either when much of it is served from the cache. alec muffet has the right ideas. but you might want to study his threat-model before copy pasting.