Comment 1:

https://golang.org/cl/14638043/

Comment 3:

are you suggesting that setting netgo build tag won't enable the Go DNS resolver?
but the code could resolve DNS names, and the binary is indeed statically linked,
so i'm not sure what's the problem.

Comment 4:

> are you suggesting that setting netgo build tag won't enable the Go DNS resolver?
Yup.
> but the code could resolve DNS names,
See net/lookup_unix.go.
func lookupIP(host string) (addrs []IP, err error) {
        addrs, err, ok := cgoLookupIP(host)
        if !ok {
                addrs, err = goLookupIP(host)
        }
        return
}
> and the binary is indeed statically linked,
It doesn't matter in this case.
> so i'm not sure what's the problem.
Hm, probably I'm wrong. Please try to build and run "CGO_ENABLED=1 && -tags netgo"
image. Hope syscall trace tool will show something something.

Comment 5:

> Hope syscall trace tool will show something something.
If you see the image does some IP-layer reachability tests to the records in query
response messages, that might be the signature of more powerful external DNS resolver
because our netgo resolver doesn't implement such kind of feature so far.

Comment 6:

i write a simple program, and use -tag netgo to build it, it can resolve www.google.com
and strace(1) verifies that it did connect to 8.8.8.8 to resolve the DNS.
the most important thing is: it is statically linked, so it couldn't possibly use the cgo
lookup code (which by definition means the binary must be dynamically linked to use
libc)
and I also verified with ltrace(1) that if i remove the netgo build tag, and rebuild the
stdlib and the program, it will call getaddrinfo(3).

Comment 7:

Thanks for the confirmation.
> and rebuild the stdlib and the program
Hm, seems I forgot to rebuild stdlib, will try later.

Status changed to Invalid.