feat: add support for using a custom DialFunc

[Jorropo]

Hi, I've added a DoTDialFunc and DoHDialFunc.

This aims to make go-dns compatible with proxy usage (we want to forward it over Tor).

[ncruces]

Hi! This is a lot to digest, it'll take me a while.

For context, is the point of it that you connect over Tor through a SOCKS5 proxy like so: https://stackoverflow.com/a/40621513/867786

Are there other use cases you can think of, or is it mostly Tor?

To be honest, the number of "obfuscating" layers we're piling concerns me a bit (but hey, I started it!)

For instance, NewDoHResolver now permits configuring a DialFunc in addition to a Transport. But Transport can itself have a DialFunc (which we're both ignoring) and even a (SOCKS5) proxy. Couldn't that be used instead?

I'm sorry if I'm going to be a bit inquisitive, but if I'm going to take "maintainership" over this, I feel like I need to understand it.

[ncruces]

For DoH, I'd consider changing this instead: https://github.com/ncruces/go-dns/blob/17b24484c0e07cc7127a73ab079cf3de45c50ef8/doh.go#L86-L95

To save opts.transport.DialContext and use that (if non nil, instead of net.Dialer) to DialContext.

That should make it work with a SOCKS5 proxy and, I imagine, Tor. No?

[ncruces]

And, out of curiosity, where does cloudflare.com/welcome-hidden-resolver fit in?

I honestly know very little about Tor.

[Jorropo]

For DoH, I'd consider changing this instead:

https://github.com/ncruces/go-dns/blob/17b24484c0e07cc7127a73ab079cf3de45c50ef8/doh.go#L86-L95

To save opts.transport.DialContext and use that (if non nil, instead of net.Dialer) to DialContext.

That should make it work with a SOCKS5 proxy and, I imagine, Tor. No?

Honnestly I don't know much about DoH (we only want to use DoT, I've done DoH without thinking much about it). :)

[ncruces]

Sorry, closed in error.

[Jorropo]

Are there other use cases you can think of, or is it mostly Tor?

Yes, golang written networks. Currently we are bundeling a full Tor node in our golang binary and using SOCKS5.

But we plan to change it to a fully golang implemented node. In this case we would return an interface like :

type Dialer interface {
    Dial(network, addr string) (net.Conn, error)
    DialContext(ctx context.Context, network, addr string) (net.Conn, error)
}

And not use SOCKS5.

EDIT: Currently SOCKS5 is hidden below our bridging package. We only get https://pkg.go.dev/github.com/cretz/bine/tor#Dialer (not a very cooperative type too).

[Jorropo]

And, out of curiosity, where does cloudflare.com/welcome-hidden-resolver fit in?

I honestly know very little about Tor.

I have not tried :D I wasn't aware. I guess this should mostly works if your tor node is correctly setup, due to how tor proxying is written I'm pretty sure you would need a full SOCKS5 proxy for tor to correctly catch the hostname.

[Jorropo]

If I understand correctly :

• DoT seems fine.
• DoH is problematic because there is way too many to assign a proxy to it (http options and dialfunc).

Do you think it be good for you if I remove DoHDialFunc and reuse the old http#Transport.DialContext instead of instanciating a new net.Dialer in the DoH DialFunc ?

[ncruces]

I'm clearly terrible at using code review features here, sorry for that. This is a first of me.

---

Also do you feel strongly about the need for going through Tor to figure out your resolver addresses? Wouldn't it be simpler (more private, more secure) to simply specify those (well known) IP addresses?

Basically, what you're doing here is: you're trying to contact the DNS server configured in your OS over Tor. That can even be something in your LAN, like your router.

Unless this is really needed, I'd just drop that bit, and assume that you either specify e.g. dns.google's IP addresses, or you you resolve those outside Tor.

[ncruces]

Merged the DoT bits int f876896. I'm unsure about the correct DoH API (and can't test), so punting there. The OpportunisticResolver had serious issues, and I'm unconvinced of the privacy angle there.

Thanks!