If we do this, why just the DNS servers? What about options? Perhaps an API to set the string contents of a /etc/resolv.conf file, which we already have a parser for?

/cc @mdempsky

This will lead to hard to discover bugs in DNS configuration which can not be observed from the outside of a binary. I expect this to lead to Go binaries getting a bad reputation among people operating systems with such binaries.

Adding environment variables to achieve these effects can be observed and discovered from the outside and can implement the same API via self exec with those environment variables set.

Perhaps an API to set the string contents of a /etc/resolv.conf file, which we already have a parser for?

I think this would be unfortunate, since /etc/resolv.conf is semi OS-specific. Also, some OSes use multiple files for config (e.g., gai.conf and nsswitch.conf on Linux).

I'd rather expose dnsConfig itself somehow, though I also worry that would limit our flexibility in supporting new OS-specific resolver behavior in the future.

Or just expose some basic info like the DNS addresses, and allow to replace them.
Actually there is no way in Go to do a DNS query using a custom DNS.
Even some argument in net.Lookup* or functions which allows this could be usefult too

Does the C library allow this? If so, how?

Adding a field to net.Resolver seems like the right place if we add something. The top-level Lookup funcs use DefaultResolver.

Does the C library allow this?

I don't see any functionality like this in glibc. If it exists, it's unlikely to be portable to other OSes.

Actually there is no way in Go to do a DNS query using a custom DNS.

But if there's no way in C either, then I'm not too worried. There already exist third-party DNS clients for Go. https://github.com/miekg/dns in particular is very good.

I think we know how we'd do this. What's missing so far is a strong justification for adding that API complexity. Why is this important to users? In what context does it make sense to override the DNS config in Go but not other languages, or in one program but not others? Why not just always override system-wide?

In C, you can change the set of name servers to query by calling res_init and then changing the nscount and nsaddr_list fields of the _res global variable declared in <resolv.h>. This is not seriously documented, but programs do it, and books refer to it; e.g., the O'Reilly DNS and Bind book: http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch15_02.htm .

So it could be done with something like:

// #include <resolv.h>
import "C"
...
net.DefaultResolver.PreferGo = false

C.res_init()
C.__res_state().nscount = 1
C.__res_state().nsaddr_list[0].sin_addr.s_addr = 0xDEDE43D0 // resolver1.opendns.com

net.LookupIP("example.com")

PreferGo = false doesn't do what you think. False is the default (zero) value. That boolean only prefers Go. It doesn't prefer C if false.

ok, so it could be done with that snippet and GODEBUG=netdns=cgo

If we do implement this, let's make it force use of the pure Go resolver and not try to implement in C by scribbling over C library data structures.

What I wrote above is still true:

What's missing so far is a strong justification for adding that API complexity. Why is this important to users? In what context does it make sense to override the DNS config in Go but not other languages, or in one program but not others? Why not just always override system-wide?

The context is: sending a DNS request to a specific server instead of the system one,
without having to create and send the packet by hand (and parse the reply as well)

@teknoraver That's not context. That's a restatement of the feature. It doesn't answer any of the questions in my previous two replies.

Still waiting on context. In addition to:

What's missing so far is a strong justification for adding that API complexity. Why is this important to users? In what context does it make sense to override the DNS config in Go but not other languages, or in one program but not others? Why not just always override system-wide?

I also wonder when that's appropriate but https://github.com/miekg/dns is not the answer instead.

I needed to do a DNS query to a custom server, I tought that changing the configured servers could be an option,
but maybe adding API to do lookup using a server is better

It sounds like this proposal is maybe a little too specific, but @bradfitz points out pending CL https://go-review.googlesource.com/c/37260 that would enable this and some other kinds of overrides. Maybe that CL should be turned into a separate proposal issue and this one closed?

ok I agree with the custom Dialer

Declining because (1) there doesn't seem to be a compelling use case and (2) apparently #19910 will be good enough.

Hey guys, I know this issue is closed but I'm having a hard time figuring out how #19910 helps with this.

I am trying to do the following.

func GoogleDNSDialer(ctx context.Context, network, address string) (net.Conn, error) {
	d := net.Dialer{}
	return d.DialContext(ctx, "udp", "8.8.8.8:53")
}

r := net.Resolver{
	Dial: GoogleDNSDialer,
}
ctx := context.Background()
ipaddr, err := r.LookupIPAddr(ctx, "www.example.com")
if err != nil {
	panic(err)
}
fmt.Println("DNS Result", ipaddr)

Yet r.LookupIPAddr isn't using the custom dialer and is still using the default resolver from resolvconf.

@artooro We don't use the issue tracker for questions, especially not on closed bugs. Please use a forum. See https://golang.org/wiki/Questions . Thanks.

When I try setting the Dial field in net.Resolver, it is used. When you ask on the forum, please provide a complete example.

@ianlancetaylor sorry will do that going forward. But just in case anyone searches and finds this, turns out all I had to do was set PreferGo to true making the code:

r := net.Resolver{
	PreferGo: true,
	Dial: GoogleDNSDialer,
}

It wasn't obvious from the docs that PreferGo needed to be set in order for Dial to be used.