feat: allow localhost http endpoints

[aschmahmann]

Allows using HTTP in addition to HTTPS as a DNS endpoint. This makes self-hosting DNS resolvers much easier as there's no need to get a domain name, TLS certs from a CA, etc. One particular example of this is making it easier for folks to self-host local non-ICANN resolvers such as for ENS, Handshake, OpenNIC, etc.

Related to ipfs/boxo#645

[marten-seemann]

This is insecure and should not be implemented. It is in direct violation of RFC 8484: DoH is DNS over HTTPS, not DNS over HTTP.

[aschmahmann]

This is insecure

Insecure is not a "thing" by itself. Security is relative to a security model. For example, in the context of web browsers (generally a security-sensitive space) a context is considered "secure" under a particular security model (see https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts). That model includes HTTPS with TLS certificates bound to domain names and certified by trusted Certificate Authorities, but it also includes HTTP requests to locahost, 127.0.0.1, etc.

Is there a particular security concern / model that you had in mind?

It is in direct violation of RFC 8484: DoH is DNS over HTTPS, not DNS over HTTP.

That's true, and yet due to the inconvenience of this coupled with the fact that it is trivial to support DNS-over-HTTP in addition to DNS-over-HTTPS other applications used widely in the DNS space have chosen to support this.

For example: CoreDNS

• Server code allows this support plain HTTP for DoH coredns/coredns#4997. The motivation here seems to be that requiring TLS termination to be combined with the DNS over HTTP logic is overly restrictive and was causing problems for people who wanted custom TLS termination
• Client code allows this [DoH] Make protocol parsing more flexible coredns/coredns#5762. The motivation in that PR seems to be that people sometimes wanted to be able to use HTTP instead of HTTPS, for example wanting to have much simpler tests without needing self-generated certs and custom TLS verification

For example: Bind9 / dig (maintained / under the umbrella of https://www.isc.org/)

• Server code: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4644
• Client code: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4672

I didn't spend as much time digging in there, but dig has DNS over plain HTTP mode and that PR to bind9 calls out support for DNS over plain HTTP

In short, it seems like the RFC attempted to be very prescriptive about using HTTPS, but since with many stacks it's fairly straightforward to support both HTTP and HTTPS and there's utility in supporting HTTP a number of groups have chosen to ignore the RFC and support both HTTP and HTTPS anyway.

and should not be implemented

So to the matter at hand. Why not?

1. It would make testing and debugging much nicer
2. It would make it much easier for people to spin up their own DoH servers on localhost that could be plugged into applications
3. Others major players in the DNS library space have gone down this route, why should this library be more restrictive?
4. It's a 1 line change

[lidel]

Hm.. my understanding of motivation behind this PR is to allow use of self-hosted custom resolver.

Such things, to make sense, have to run on localhost, and do not go unencrypted over network. Approach similar to how web browsers mark localhost as secure context, and expose windo.crypto and other Web APIs even when the root document was loaded from local server without TLS.

Agree we should not allow unencrypted HTTP outside of localhost – misconfigurations happen and RFC Marten mentioned is stric ton purpose, to avoid situation where people's DNS queries are sent in cleartext over network.

As a pragmatic compromise, pushed 18cfb6d with refactor that limits this PR to localhost, following spirit of secure contexts in browsers and https://datatracker.ietf.org/doc/html/draft-west-let-localhost-be-localhost

If non-localhost http:// URL is used, NewResolver returns an error.
Added tests to ensure this behavior does not regress.