Skip to content
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

Closed
miekg opened this issue Jul 5, 2018 · 4 comments
Closed

DoH support #707

miekg opened this issue Jul 5, 2018 · 4 comments

Comments

@miekg
Copy link
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 DoH i DoH support Jul 5, 2018
@tmthrgd
Copy link
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
Copy link
Owner Author

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 :)

@tmthrgd
Copy link
Collaborator

tmthrgd commented Nov 26, 2018

With #800 merged, this issue seems fixed.

@tmthrgd tmthrgd closed this as completed Nov 26, 2018
@shynome
Copy link

shynome commented Aug 25, 2023

if anyone need doh-client support, you can use my lib doh client and this lib to query dns over https

package main

import (
	"fmt"

	"github.com/miekg/dns"
	"github.com/shynome/doh-client"
)

func main() {
	q := dns.Question{
		Name:   dns.Fqdn("remoon.net"),
		Qtype:  dns.TypeA,
		Qclass: dns.ClassINET,
	}
	m := &dns.Msg{
		MsgHdr:   dns.MsgHdr{Id: dns.Id(), Opcode: dns.OpcodeQuery, RecursionDesired: true},
		Question: []dns.Question{q},
	}
	co := &dns.Conn{Conn: doh.NewConn(nil, nil, "1.1.1.1")}
	if err := co.WriteMsg(m); err != nil {
		panic(err)
	}
	m, err := co.ReadMsg()
	if err != nil {
		panic(err)
	}
	if len(m.Answer) == 0 {
		panic("answer length must greater than 0")
	}
	fmt.Println(m.Answer)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants