Support for Oblivious DNS client

[folbricht]

Draft implementation of Oblivious DNS. Client-only for now if anyone wants to give it a try. The resolver config looks like this:

[resolvers.cloudflare-odoh-proxy]
# Address of the odoh proxy server. Also used to resolve the target's key
address = "https://1.1.1.1/dns-query"
protocol = "odoh"
# Address of the target. The hostname and path are passed to the proxy for forwarding
# of encrypted queries. No cert or bootstrap options for the target since the proxy
# connects to it on the client's behalf
target = "https://odoh.cloudflare-dns.com/dns-query"

Currently, I use Cloudflare as proxy and target which sort-of defeats the purpose of odns, but it's just for testing anyway. Don't know of any other proxies that support it yet.

Todo:

• DNSSEC validation of the target key response
• Docs
• Tests

Ref #116

[cbuijs]

The first post in this thread confuses me, the target is the ODoH proxy, and the address the "plain" DOH server (the DoH target using the ODoH proxy), right?

Might want to change target into odoh-proxy or something.

The cloudflare documentation on this confuses me as well, so it could be me :-).

[folbricht]

hmm, I may have to work on the docs :) So the plain address is the "proxy", with "target" being the thing that will ultimately answer the encrypted query. The proxy has 2 jobs in RouteDNS:

1. Resolve the target's key, using a regular query. So it's not just a proxy, it's also a regular resolver (the DoH queries have different headers for proxy vs regular lookup)
2. Forward the encrypted query (encrypted by the client for the target) to the target and sending the response back the same way

Going to add a diagram when done with the implementation

[cbuijs]

That is allright, the example works, but when people want to "disconnect" the proxy and the target (not being the same supplier for example), it might not be clear what to do, maybe point out with examples (we need more proxies though).

Seems that this is done by Cloudflare, Apple, Fastly, PCCW, equinix and SURF, none of them with the exception of Cloudflare offer anything yet as a proxy (I couldn't find any - yet).

Also not clear yet for me that if any PROXY will actually work or can be used, as long as you publish the keys in DNS and TLS can be used as transport. The whole proxy thing is an enigma at the moment for me and what is so special about it (other then it is "disconnected" from the DNS provider), as it is still HTTPS/TLS transport, right? (Does it use CONNECT?).

So much to read after the vacation :-)

[folbricht]

Yes, another public proxy would be great in the example, or a different target with Cloudflare as proxy.

It's actually much simpler, the proxy is always something that speaks DoH (the target too). The only difference is that it should recognize a different content header and additional query params to tell it to forward somewhere else. When it does forward, it does not work like a normal proxy (CONNECT) where the client is connected to the target and they talk. Instead, the proxy receives an encrypted query which is really just random-looking bytes from the proxy's point of view. It then just sends those bytes to the target and opens its own TLS connection to the target and again speaks DoH with the target sending those raw bytes (different content header again).. The client has no influence on the TLS link between proxy and target.

[cbuijs]

Using "PROXY" in a "HTTPS" context is my muscle-brain memory kicking in for sure. :-) - Thanks for ellaborating, was just reading that as well.

[alpominth]

Any plans to finish DNSSEC validation and make this branch ready?

[folbricht]

Having a DNSSEC validator as part of RouteDNS would be awesome. Unfortunately it's also quite complex and I really don't have the time to work on it. Doing this would require at least a full week of work, possibly more. Can't say if I'll get to that any time soon.

[cbuijs]

@folbright

Maybe check (if not done already) GoResolver?

Note: Maybe we should continue this conversation at #123 ?

[ignoramous]

unfortunately, not all odoh servers publish https/svcb record. in fact, RFC-9230 has removed it from spec (from draft-07 to be precise).

attempting to fetch odoh-config from both, /.well-known/odohconfigs and https/svcb records, is a safer bet. we do this for our android app, rethink (code). cloudflare's reference implementation also does the same.