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: Support the /etc/resolver DNS resolution configuration hierarchy on OS X #12524

Open
Rotonen opened this issue Sep 6, 2015 · 63 comments
Open
Labels
help wanted NeedsInvestigation OS-Darwin
Milestone

Comments

@Rotonen
Copy link

Rotonen commented Sep 6, 2015

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/resolver.5.html

OS X allows you to add TLD specific resolver configurations. Quite popular ones are /etc/resolver/vm for local virtual machines and /etc/resolver/dev for local development purposes.

https://golang.org/src/net/dnsclient_unix.go#L231

Go seems to be hardcoded to only take /etc/resolv.conf into account on Unix platforms.

@nodirt
Copy link
Contributor

nodirt commented Sep 6, 2015

I don't think Go-native DNS resolving mechanism is used on Mac.
https://golang.org/src/net/dnsclient_unix.go#L231 is not executed if I run

addrs, err := net.LookupHost("google.com")

on my Mac.

If I enable debugging (GODEBUG=netdns=2 go run test.go), the following is printed:

go package net: using cgo DNS resolver
go package net: hostLookupOrder(google.com) = cgo

which means that OS-native DNS resolving is used.

Can you supply an exact configuration file, Go code, actual and expected output?

@titanous
Copy link
Member

titanous commented Sep 6, 2015

@nodirt This is for a binary with cgo off.

@davecheney
Copy link
Contributor

davecheney commented Sep 6, 2015

If cgo is disabled then the pure go DNS resolver will be used. If you want
to use the Mac DNS resolver, plese build with cgo.

On Mon, 7 Sep 2015 07:47 Jonathan Rudenberg notifications@github.com
wrote:

@nodirt https://github.com/nodirt This is for a binary with cgo off.


Reply to this email directly or view it on GitHub
#12524 (comment).

@nodirt
Copy link
Contributor

nodirt commented Sep 6, 2015

Shouldn't be a problem since this is needed only on a dev machine.

On Sun, Sep 6, 2015 at 4:06 PM Dave Cheney notifications@github.com wrote:

If cgo is disabled then the pure go DNS resolver will be used. If you want
to use the Mac DNS resolver, plese build with cgo.

On Mon, 7 Sep 2015 07:47 Jonathan Rudenberg notifications@github.com
wrote:

@nodirt https://github.com/nodirt This is for a binary with cgo off.


Reply to this email directly or view it on GitHub
#12524 (comment).


Reply to this email directly or view it on GitHub
#12524 (comment).

@titanous
Copy link
Member

titanous commented Sep 6, 2015

In this specific case, @Rotonen was using the Flynn binary that we distribute as a compiled artifact, it is compiled without cgo to ease cross-compilation. Just because the user is a developer doesn't mean that they are a Go developer or want to compile the binary for themselves. The only question here is if this feature is out of scope for the pure-Go resolver.

@minux
Copy link
Member

minux commented Sep 7, 2015

@ianlancetaylor ianlancetaylor changed the title Support the /etc/resolver DNS resolution configuration hierarchy on OS X net: Support the /etc/resolver DNS resolution configuration hierarchy on OS X Sep 8, 2015
@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Sep 8, 2015

I don't see anything wrong with supporting the OS X /etc/resolver directory. That said, my understanding is that the Go DNS resolver does not work well on most OS X machines. That is why it is disabled by default.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Sep 8, 2015
@mterron
Copy link

mterron commented Jun 1, 2016

This would be great in all platforms anyway. Is there any disadvantage from supporting this behaviour? It seems that it'd neatly resolve the need to install and configure dnsmasq to provide the simple function of having different resolvers for different TLDs.

@jason-riddle
Copy link

jason-riddle commented Feb 16, 2017

i know this issue is quite old but has there been any traction on this?

@ghost
Copy link

ghost commented Jun 23, 2017

any resolution?

@bradfitz
Copy link
Contributor

bradfitz commented Jun 23, 2017

Any updates would be posted here. No updates have been posted here.

@bradfitz bradfitz added help wanted NeedsInvestigation labels Jun 23, 2017
@bitglue
Copy link

bitglue commented Apr 20, 2018

See resolver(5). Just reading the files out of /etc/resolver/* will miss out on other mechanisms for configuring the same thing, for example configuration profiles or IKE attributes.

@flyinprogrammer
Copy link

flyinprogrammer commented Sep 25, 2018

Just stumbled upon this today while attempting to use coredns as a dns proxy for local development. It's a real bummer to discover how naive our support for os x is.

@bradfitz
Copy link
Contributor

bradfitz commented Sep 25, 2018

We've generally assumed people use cgo on Darwin, so this bug has never been a priority.

I do admit that practically means that Darwin binaries need to be built on Darwin, which is difficult for people wanting to cross-compile for a dozen platforms as part of their release process.

Perhaps on Darwin without cgo we could just shell out to a program to do DNS resolution (e.g. host, dig, nslookup?). At least nslookup has an interactive mode that would permit re-using a child process for multiple lookups, if that proves necessary for performance.

@apparentlymart
Copy link

apparentlymart commented Aug 26, 2021

Earlier on I described how the Terraform team at HashiCorp uses cross-compilation to build for multiple platforms, and thus our darwin_amd64 releases end up not having cgo enabled.

In the interests of keeping things current, I just wanted to note that in conjunction with reworking our build process to support other macOS-specific chores such as notarization and building for the new darwin_arm64 platform we have now abandoned cross-compilation as our build strategy for the official Terraform releases, and thus this problem is no longer such a high pressure for Terraform users who choose to use the binaries we produce.

However, there are still various people who for one reason or another build Terraform from source themselves, and they can unknowingly end up producing a build that has significantly different DNS resolution behavior than the official builds depending on what strategy they take to do so. Also, the Terraform artifacts we produce are used in conjunction with a variety of other plugin executables, many of which are built by teams at other companies who have devised their own release strategies which may or may not be using cross compilation or enabling cgo, and so this situation does still remain somewhat problematic for some smaller cohorts in our community.

Overall it feels unfortunate to me that the DNS resolution behavior of Go programs can vary so drastically depending on how they are built, whereas in most other regards the Go toolchain does a great job of ensuring consistency regardless of strategy. I think a number of Go-based codebases have gone through this sequence of being naive to that possibility, and then learning too late that this difference exists as a result of a likely-frustrating debugging session where the root cause exists outside of the developers' typical field of view.

With that said, I do understand that there isn't a super clear answer here, since DNS resolution behavior for Unix-alike systems has traditionally been the responsibility of a system's C library. If there isn't a viable way for Go to exhibit the correct DNS resolution behavior without interacting with libc using cgo then I hope instead for some inspiration on how to make this quirk more visible to developers, so they aren't given false optimism by how well the Go toolchain typically handles cross-compilation.

@blalor
Copy link

blalor commented Aug 26, 2021

jwhonce added a commit to jwhonce/podman that referenced this issue Oct 14, 2021
Need to use CGO for mDNS resolution, but cross builds need CGO disabled
See golang/go#12524 for details

Note: Homebrew forumla will need to be updated to pick up this change

Fixes containers#10737

Signed-off-by: Jhon Honce <jhonce@redhat.com>
jwhonce added a commit to jwhonce/podman that referenced this issue Oct 14, 2021
Need to use CGO for mDNS resolution, but cross builds need CGO disabled
See golang/go#12524 for details

Note: Homebrew forumla will need to be updated to pick up this change

Fixes containers#10737

Signed-off-by: Jhon Honce <jhonce@redhat.com>
jwhonce added a commit to jwhonce/podman that referenced this issue Oct 14, 2021
Need to use CGO for mDNS resolution, but cross builds need CGO disabled
See golang/go#12524 for details

Note: Homebrew forumla will need to be updated to pick up this change

Fixes containers#10737

Signed-off-by: Jhon Honce <jhonce@redhat.com>
zeha pushed a commit to zeha/podman that referenced this issue Nov 17, 2021
Need to use CGO for mDNS resolution, but cross builds need CGO disabled
See golang/go#12524 for details

Note: Homebrew forumla will need to be updated to pick up this change

Fixes containers#10737

Signed-off-by: Jhon Honce <jhonce@redhat.com>
@apparentlymart
Copy link

apparentlymart commented Jan 6, 2022

I wanted to add one further update here, in case it's useful to anyone who is referring to this issue while trying to debug resolver-related problems for macOS builds:

By default, the Go toolchain automatically disables CGo when cross-compiling, which means that if you're running something like GOARCH=arm64 go build on a darwin_amd64 Go toolchain in the hope of cross-compiling for Apple Silicon you will, by default, produce an executable with similar incorrect resolver behavior as would arise when e.g. cross-compiling for macOS from Linux.

However, in our experimentation so far we've found that there's sufficient support in the development tools for macOS x86_64 to generate an Apple Silicon binary that can dynamically link with libc at runtime -- I assume, but have not verified, that this works due to there being suitable libc headers for both targets in the system toolchain -- and so it seems to work to force-enable CGo when cross-compiling between architectures as long as both host and target are macOS (darwin, in Go target terms):

CGO_ENABLED=1 GOARCH=arm64 go build

This can be particularly useful when you are building on a build automation platform that only offers amd64 workers, but still need to produce Apple Silicon binaries. I hope that's helpful to folks who are monitoring this issue due to having been burned by this before! 😀

@atrigent
Copy link

atrigent commented Jul 30, 2022

@grantseltzer I don't know if this issue is still on your radar, but if it is, it doesn't seem like the issue here is just about convincing the Go maintainers to accept this functionality. There are some important issues called out in the revert that are holding up re-introducing this code, most notably that it is calling the wrong function in the wrong library. If you could fix that issue then I think that would go a long way toward getting this fixed once and for all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted NeedsInvestigation OS-Darwin
Projects
None yet
Development

Successfully merging a pull request may close this issue.