Feature: Add DNS-over-HTTPS (DoH) support

[bradh352]

This would require adding a dependency on a cryptographic library like OpenSSL, and because of this it would be an optional feature.

It would also require thought on how to configure DoH servers since you need to know its FQDN as well as its possible IP addresses up front as you don't want to use classic DNS to resolve the IP from the FQDN as your system may not have any classic DNS servers available.

We should write a very minimal HTTP/2 parser/writer and not rely on yet another 3rd party library since our usage would be very minimal. We should also follow best practices on possibly using OPT RR Padding to pad requests to some recommended lengths to prevent information disclosure.

[bagder]

We should write a very minimal HTTP/2 parser/writer and not rely on yet another 3rd party library

I strongly advice against this. HTTP/2 is complicated and never "minimal".

[bradh352]

Its not that complex :) HPACK is probably the most non-obvious component. But for as small a subset of HTTP/2 we'd need for DoH it doesn't make sense to bring in a large security footprint of something like nghttp2. If we could get support for under 2k lines of code, I think it'd be worth it, and we already have some memory safe parsers and buffer builders and basic data structures now days that makes it a heck of a lot easier to build off of.

[bagder]

I won't stop you, but my view is different.

[bradh352]

I'll admit I have a bit of a "not-invented-here" syndrome when it comes to 3rd party C code :) But in my defense, I think C has earned the reputation that just because a lot of people use it doesn't make it good or secure.

[bagder]

I just think you underestimate the amount of work. HTTP/2 won't be enough, you'll need HTTP/1 as well. Probably need to support redirects. Probably proxy as well. And no complete and working HTTP implementation was ever simple.

[bradh352]

RFC 8484 says the minimum version is HTTP/2. I'd be ok with that limitation and not support some odd provider that only supports HTTP/1.1. HTTP/2 is required for async requests which I'd make a minimum requirement for this since c-ares is all async and breaking that would be non-trivial. I'd also be ok not allowing redirects since a redirect could cause issues with certificate verification since if it wasn't at the same domain it would require a dns lookup (chicken and egg type thing with DoH). I'd consider a redirect a security risk as well.

[bagder]

You can certainly do HTTP/1 async just as "easy" as you can do HTTP/2 async. The main difference is that with h2 you can do both A and AAAA requests in parallel over the same connection while with h1 you need two.

BTW, HTTP auth is also fairly common for DoH users to restrict usage.

[Arkiver2]

Great to see activity on this issue!

A small note, RFC 8484 section 5.2 notes that HTTP/2 is "the minimum RECOMMENDED version of HTTP for use with DoH", so it is not necessarily a forced (not a "REQUIRED") minimum version. This would mean that DNS servers that support DoH may support HTTP/1.1 for some valid reason. I believe this would mean that clients talking using DoH should support HTTP/1.1 in case the server has some good reason to support (only?) HTTP/1.1.

c-ares is a general library for DNS requests, so it would be good to have support for HTTP/1.1. I would think it would indeed not be too hard to support HTTP/1.1 as well next to HTTP/2 (but I would not be the one implementing this - so I may be wrong here).

An extra request from my side would be an option to allow c-ares to talk with only HTTP/1.1 or only HTTP/2 for DoH (or both with HTTP/2 preferred if the option is not set).

[bagder]

@Arkiver2 absolutely, HTTP/1 is commonly used for DoH (I wrote the original implementations for Firefox and curl and I've seen lots of that).