net: respect GODEBUG=netdns=go on macOS

[gregory-m]

What version of Go are you using (go version)?

go version go1.11 darwin/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

Can be reproduced on any darwin.

What did you do?

Tried to debug some DNS issues on our production system.

In order to do this I tried to run code with GODEBUG=netdns=go+2 and GODEBUG=netdns=cgo+2 on my local Mac.

What did you expect to see?

Go runtime will use cgo or go resolver according to GODEBUG env variable.

What did you see instead?

Runtime silently used cgo resolver every time.

Also despite this comment I don't see any popups after I removed this check.

Can we put darwin check before if confVal.dnsDebugLevel > 0 and use go resolver on darwin if user explicitly asked for it?

If there are no objections I will create CL.

[bcmills]

CC @mikioh @bradfitz @ianlancetaylor

[bradfitz]

As long as we continue to default to using the cgo resolver on Darwin, I'm fine respecting the GODEBUG knob on Darwin to select the pure-Go resolver. (and perhaps the build tag, too?)

[gregory-m]

After some investigation looks like Darwin will popup dialog box if developer mode in not enabled on Mac. However it not popup dialog box on some Macs without developer mode been enabled, and I can't found any version or setting correlating with such behaviour.

In any case I don't think build tag is good idea, because some user will definitely see popups on Mac if you compile and distribute binary with pure-Go resolver enabled by default.

However GODEBUG is useful for local debugging.

[rsc]

Respecting $GODEBUG seems OK - if you ask for it, you get it. I wouldn't want to do hard-coding at build time, though, since we know that the non-cgo resolver is much worse than the cgo one (see #12524).

[bradfitz]

TIL:

$ DevToolsSecurity -status
Developer mode is currently enabled.

Not sure when I enabled that.

[bitglue]

I've been using the same work laptop for 2 years and never enabled developer mode:

$ DevToolsSecurity -status
Developer mode is currently disabled.

and I've never seen this popup despite running plenty of go binaries built with cgo disabled. I tried enabling the firewall in system preferences, and still can't reproduce the popup. Nor have I received any reports of such a popup from my coworkers. Though I do get a lot of complaints about DNS failing to resolve private hostnames, an indication that the native go resolver is in use.

Point being, whatever determines if this popup occurs, I don't think it's developer mode.

Furthermore, on my system I can't reproduce the problem: GODEBUG does seem to be honored. With this test program:

package main

import (
	"fmt"
	"net"
)

func main() {
	ns, err := net.LookupHost("philfrost.local")
	if err != nil {
		panic(err)
	}
	fmt.Println(ns)
}

built with:

philfrost:~ philfrost$ go build -o test ./test.go
philfrost:~ philfrost$ go version
go version go1.10.2 darwin/amd64
philfrost:~ philfrost$ system_profiler SPSoftwareDataType
      System Version: macOS 10.13.6 (17G65)
      Kernel Version: Darwin 17.7.0
      System Integrity Protection: Enabled

cgo resolution works:

philfrost:~ philfrost$ GODEBUG=netdns=cgo+2 ./test
go package net: using cgo DNS resolver
go package net: hostLookupOrder(philfrost.local) = cgo
[192.168.1.167]

Go's native resolver is used when requested, confirmed by the debug output as well as the resolution failure (native Go can't resolve RFC6762 names):

philfrost:~ philfrost$ GODEBUG=netdns=go+2 ./test
go package net: GODEBUG setting forcing use of Go's resolver
go package net: hostLookupOrder(philfrost.local) = files,dns
panic: lookup philfrost.local on 192.168.1.1:53: no such host

goroutine 1 [running]:
main.main()
	/Users/philfrost/test.go:11 +0xde

[bradfitz]

@bitglue, I also see that.

@gregory-m, can you try again? Sure you're using the version of Go you think you are?

[ianlancetaylor]

It sounds like people think that this already works. @gregory-m do you disagree?

[gregory-m]

Sorry my bad, tried it with wrong build. Works as expected in current version.