New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DoH support #707

Open
miekg opened this Issue Jul 5, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@miekg
Owner

miekg commented Jul 5, 2018

I'm coming back on the need of having DoH support directly in this library.

HTTP(/2) is a different beast and we should probably defer those implementation bits to net/http and friends.

What we do want to support is creating a Get or Post request and than handing it off.

Connection re-use and all kinds of complication could then be left out of this libary as it (mostly) deals with DNS binary conversions.

DNS over TCP (DoT) remains an interesting one; because that requires some of the bits (connection reuse, etc). and is easier to support because it is a simpler protocol.

@tmthrgd wdyt?

@miekg miekg changed the title from DoH i to DoH support Jul 5, 2018

@tmthrgd

This comment has been minimized.

Collaborator

tmthrgd commented Jul 7, 2018

@miekg I’m not sure I agree. Everything connection-reuse related is entirely internal to net/http, as is everything HTTP(2). The transports that have complications regarding reuse are DNS-over-TLS and DNS-over-TCP.

In my eyes, the complication with DOH in this library comes entirely down to the existing API, which it doesn’t match up quite perfectly to.

If DOH support were to be removed from this library, I wouldn’t suggest adding any request creation functions in its place. It’s mostly trivial to construct a DOH request.

I think there’s value in having support for a secure transport that seems likely to gain adoption and use. (Granted there is no server support yet).

@miekg

This comment has been minimized.

Owner

miekg commented Jul 25, 2018

If DOH support were to be removed from this library, I wouldn’t suggest adding any request creation functions in its place. It’s mostly trivial to construct a DOH request.

I agree with this.

As to "it doesn't fit the API", that's true; but that requires a lot of work and I don't think anyone has time for that.
If starting implementing DoH client support in CoreDNS, and there is nothing that I wanted from this lib (unless it had a perfect implementation).

So, until there is a plan and time to properly implement a Client2, DoH should be dropped. The lack symmetry with the server is also jarring in my mind :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment