I'm using numa(https://github.com/razvandimescu/numa) for ad filtering and odoh mode for privacy (shameless plug)

So this is something to use instead of pihole?

I run a small local resolver (numa, github.com/razvandimescu/numa). When configured on doh or odoh upstream it would protect you from attacks such as this one

Wow this led me on an interesting rabbit hole about what odoh is.

Very interesting!

running my own resolver as system DNS i can confirm apple devices fire _dns.resolver.arpa on every network join, but since verified DDR needs a TLS cert covering the resolver's IP it's effectively public-resolver-only, so for a LAN resolver the right move is just answering NODATA instead of leaking the query upstream.

> since verified DDR needs a TLS cert covering the resolver's IP it's effectively public-resolver-only

Why would you think this? It's trivial to get certs for internal services that mainstream devices trust, they just have to use names from a portion of the public DNS space that you can demonstrate control over. It doesn't actually have to be publicly exposed.

might want to check https://github.com/alexandru/social-publish

actually that is exactly how i am currently running it - dogfooding from my Mac

sudo numa install handles launchd, numa then becomes tailscale's fallback resolver

docker socket service discovery - on the roadmap

honestly, nothing major, just deployed the docker-compose to a hetzner $5 instance https://github.com/razvandimescu/numa/tree/main/packaging/re...

then submit a pr to Frank https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v...

sovereign naming without ICANN or registrars - pkarr through DHT (not blockchain)

That's really great. I apologize for my initial cynicism. How can you address something like namesquatting if it's first-come?

The relay sees IP + ciphertext, the target sees question + relay's IP. No single party gets both

What if the relay and target are being operated by the same provider? The relay controls where the question is sent right? They can collude?

no, you are actually telling the relay where to redirect your question from the start (because you are encrypting the question with the public key of the destination resolver) - the relay sending the question where it wants would result in the destination to not be able to decrypt it

If relay and target are operated by the same provider, there is no collusion. Collusion occurs between 2+ parties. You have stipulated that they are the same party.

"They can collude?"

There are no limitations on what these parties can do with the data they collect or where they can transfer it

They solve different things. ODoH hides your question, not who you're talking to.

Sure ODoH hides your query but you then turn around and leak the question you just asked as part of the TLS handshake.

Leaked to different parties.

Assuming you don't have ECH, you leak the question (in practical terms) to your ISP, and you leak your question to the DNS provider. With ODoH you plug the latter leak. Plugging that first leak is then still a problem (solved separately) but it's orthogonal to the second.

Even with ECH, where you plug the TLS leak, you have many more holes to plug. IP address might not be shared or might be shared across too few properties, and then traffic profile after the initial connect (to retrieve all the sub-resources) can identify destinations.

It's not limited to the ISP and DNS provider. Thanks to being plaintext it's anyone anywhere along the network path (unless you were already using DoH of course, but sans-ECH is still the entire path regardless).

Anyway I agree with you that plugging leaks is good (notice my adjacent comment). My response there was intended to provide clarification regarding the preceding exchange.

Going off on a tangent, I wish there were more awareness of how this concentrates power to Cloudflare.

Between so many service operators intentionally purchasing MitM as a service from the cloud providers and the ever increasing proliferation of centralized captcha solutions that work via fingerprinting the entire situation seems increasingly hopeless.

I agree with you, however that's a separate problem that needs to be solved

The relay is a systemd unit on a VPS, Caddy for TLS, SSRF-hardened (regex-strict hostnames, no IP literals). eTLD+1 same-operator check rejects relay+target run by the same org by default. HPKE is odoh-rs from Cloudflare

``` cargo install numa

# set mode = "odoh" in numa.toml ```

Repo: https://github.com/razvandimescu/numa