CLI DNS is resolved using nameservers in resolv.conf only

[khumps]

When using the CLI it appears that only the first nameserver in /etc/resolv.conf is used to resolve dns records. resolv.conf is no longer the primary dns on most operating systems and golang no longer uses it as the primary source as of golang 1.13 This results in incorrect dns resolution for anyone who hasn't manually set their DNS in their resolv.conf file to the correct DNS server and completely breaks if one is using split DNS such as is the case for a split-tunnel VPN.

Example

/etc/resolv.conf (doesn't work)

#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns
#
# SEE ALSO
#   dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
search DOMAIN_NAME
nameserver DEFAULT_GATEWAY_NAMESERVER

result of hasura migrate status

FATA[0001] version check: failed to get version from server: failed making version api call: Get https://GRAPH_QL_URL/v1/version: dial tcp: lookup GRAPH_QL_URL on WRONG_DNS_SERVER:53: no such host

/etc/resolv.conf (with secondary DNS server)

#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns
#
# SEE ALSO
#   dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
search DOMAIN_NAME
nameserver CORRECT_DNS_SERVER

result of `hasura migrate status (with secondary correct DNS server)

VERSION NAME SOURCE STATUS DATABASE STATUS (I don't have anything set up yet so this is expected)

I tried to fork the repo and build using golang 1.14 without gox but that did not appear to fix the issue so there is perhaps more of an issue internally

[scriptonist]

Thanks for bringing this to notice @khumps, I see that this is a known issue with cross-compiling binaries with the CGO disabled. We'll explore how we can best tackle this. In the meantime can you see if projects like https://github.com/greenboxal/dns-heaven will help you or maybe build from source with CGO_ENABLED for now?

I'm pinning a bunch of related issues here for future reference,

• net: Support the /etc/resolver DNS resolution configuration hierarchy on OS X when cgo is disabled golang/go#12524
• Build kubectl binary with cgo enabled kubernetes/release#469
• helm3 - macOS binary does not resolve vpn hosts helm/helm#5800

[khumps]

I tried compiling with the following command:
CGO_ENABLED=1 go build -ldflags '-X github.com/hasura/graphql-engine/cli/version.BuildVersion=master-f2428e39-dirty -X github.com/hasura/graphql-engine/cli/plugins.IndexBranchRef=master -s -w -extldflags "-static"' \ ./cmd/hasura/

and am still seeing the same issues 🤔

Edit: It appears to be working now with CGO_ENABLED=1

[iosifnicolae2]

Any idea how can we solve this?

Thank you!

[mbrevda]

Was this ever fixed? I'm having a seemingly similar issue where Hasura is routing calls in a way that is different from other os's