/cc @bradfitz

Review here: https://go-review.googlesource.com/19523

CL https://golang.org/cl/19523 mentions this issue.

This came up for @sneak recently: https://twitter.com/sneakdotberlin/status/720390638621995008

There's the question of what to do when nsswitch.conf contains an unsupported configuration (assuming a build with netgo set or with cgo turned off entirely). Rather than fall back to some default behavior, it might be better to return an error. It took some back and forth in that twitter thread above for us to figure out what was going on. An error message would have eliminated the confusion.

Or, on OSX, where nsswitch.conf doesn't exist at all (but *.local mdns lookups are expected to work).

For 1.7, we have a small incremental fix: we use the same resolv.conf/nsswitch.conf parsing logic that we use when cgo is available, and only when we would fall back to cgo do we instead use the old files-then-DNS logic.

netgo doesn't support mDNS anyway, so making that work correctly seems out of scope for this issue.

I think it's too late for Go 1.7 to change netgo builds to start failing with errors because of unsupported system configs. I'm also skeptical of the idea in general, but maybe there's still something we could do to make it more obvious when we're falling back to files-then-DNS. Feel free to open a new issue if you think we should look at that for 1.8.

@vishvananda I wonder if you intended that a netgo binary run on Linux with no /etc/nsswitch.conf would change from files,dns to dns,files order?

It seems like it should follow the glibc default if /etc/nsswitch.conf doesn't exist, so while I didn't realize I was changing it, the dns,files order makes more sense IMO. That said, perhaps the default fallback should actually be hostLookupDNSFiles for even more consistency with glibc. That may conflict with defaults on other Operating Systems, however.