Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: Building with netgo doesn't respect nsswitch.conf #14354

Closed
vishvananda opened this issue Feb 17, 2016 · 8 comments

Comments

Projects
None yet
7 participants
@vishvananda
Copy link
Contributor

commented Feb 17, 2016

Commit 4a0ba7a allowed golang to use its own dns resolver instead of libc in a number of cases. The code parses nsswitch.conf and attempts to resolve things in the same order. Unfortunately, builds with netgo completely ignore this parsing and always search via hostLookupFilesDNS. It seems like it would be better to parse the file and only fallback to hostLookupFilesDNS if it would normally use hostLookupCgo.

I noticed this because I have a static binary built with cgo, and it is using files for lookup even when nsswitch.conf specifies:

hosts:      dns

@mdempsky mdempsky changed the title Building with netgo doesn't respect nsswitch.conf net: Building with netgo doesn't respect nsswitch.conf Feb 17, 2016

@mdempsky

This comment has been minimized.

Copy link
Member

commented Feb 17, 2016

/cc @bradfitz

@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Feb 17, 2016

@vishvananda

This comment has been minimized.

Copy link
Contributor Author

commented Feb 17, 2016

@gopherbot

This comment has been minimized.

Copy link

commented Feb 18, 2016

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

@kr

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2016

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.

@sneak

This comment has been minimized.

Copy link

commented Apr 17, 2016

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

@mdempsky

This comment has been minimized.

Copy link
Member

commented May 4, 2016

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.

@bboreham

This comment has been minimized.

Copy link

commented Nov 18, 2016

@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?

@vishvananda

This comment has been minimized.

Copy link
Contributor Author

commented Nov 18, 2016

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.

@golang golang locked and limited conversation to collaborators Nov 18, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.