-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Consul build on OS X doesn't use System Configuration framework for DNS resolution #3267
Comments
I am fairly positive this also relates to hashicorp/terraform#5925 and that if I read that PR discussion correctly, then terraform, as well as all other tools in hashicorp stack, are critically flawed when used on OS X machines, especially in light of Consul DNS interface |
Hi @mbravorus thanks for opening an issue - we compile Consul with cgo disabled, so it's using the generic Go resolver instead of the OSX specific framework. We'd really like to avoid using cgo since Consul otherwise is pure Go, which vastly simplifies supporting all the platforms that we do with Consul. As a workaround, do you have some way of configuring the OSX DNS to delegate just .consul lookups to the Consul agent vs. having the Consul agent be the primary DNS resolver that recurses? |
Hi @slackpad, thanks for the response. I'm not entirely sure I understand why you'd want to delegate .consul lookups and how it would be a workaround for this case. The problem lies not in delegation or recursor addressing, but in the inability of "hashistack" tools themselves to use the native resolver on OS X. Therefore, no matter how I configure it, consul and terraform and others will remain blissfully unaware. What can be done (and often is), is an attempt to duplicate the native DNS configuration via the older /etc/resolv.conf system, which your binaries understand. However, it is kludgy, and often gets overwritten by automatic tools and especially in VPN-heavy context, which is exactly the context the whole problem usually arises in. Perhaps there is a way to offer a less/un-supported but "by the manufacturer" build with cgo for OS X users? That would be a functional workaround for those who are affected, without them having to reconstruct the whole build process with added unsupported element and no guidance. You, at the very least, know what you are doing :) |
Unfortunately I don't think we plan to support this in the near-term. We'd welcome a guide from the community on how to do this, but can't support it at the moment. Thanks for suggesting it, however, and feel free to comment if I've missed something here. |
Your friends who do nomad seem to have found a CD process that allows them to do this: https://github.com/hashicorp/nomad/blob/088f51a330a93186a74515b8d699f24e59611adf/GNUmakefile#L56 Also, this issue relates to this issue in core: golang/go#12524 |
consul version
for both Client and ServerClient: 0.8.5
Server: 0.8.5
consul info
for both Client and ServerClient:
Server info not relevant
Operating system and Environment details
In my particular case it is MacOS Sierra 10.12.5
Description of the Issue (and unexpected/desired result)
The issue stems from the desire to use native Consul DNS interface for service discovery. Consul cluster runs in the cloud (AWS), using private address space. A client developer machine connects to the private space via VPN. VPN server pushes out custom DNS server entries and custom domain name (consul) to search. VPN client correctly incorporates these settings into native System Configuration resolver framework. Proof:
Native applications are able to successfully query these resolvers for .consul names:
and
However, consul itself is unable to resolve such names (because it only relies on /etc/resolv.conf and not native macOs framework):
Reproduction steps
Create custom nameservers using networksetup utility (networksetup -setdnsservers), verify using 'scutil --dns', verify successful resolution with dscacheutil (see example above), verify unsuccessful resolution via consul binary
The text was updated successfully, but these errors were encountered: