cli: macOS system DNS resolver is not fully respected

Discovered another bug while working in the lab this week. Here’s my setup:

macOS 10.15.7
Connecting to a Wireguard network that has its own DNS server
I added a DNS resolver that works only for the .lab domain:

$ sudo su -
$ mkdir -p /etc/resolver
$ cat<<EOF > /etc/resolver/lab
domain lab
nameserver fd98:ae2f:c37a::1
nameserver 10.0.2.1
EOF

scutil --dns confirms that my resolver is active for the .lab domain:

resolver #1
  nameserver[0] : 10.20.30.40
  nameserver[1] : 10.20.30.41
  flags    : Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

... (bunch of mdns resolvers) ...

resolver #8
  domain   : lab
  nameserver[0] : fd98:ae2f:c37a::1
  nameserver[1] : 10.0.2.1
  flags    : Request A records
  reach    : 0x00000003 (Reachable,Transient Connection)

I can ping the CA just fine:

$ ping ca.lab
PING ca.lab (10.0.2.1): 56 data bytes
64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=5.511 ms
64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=6.246 ms
64 bytes from 10.0.2.1: icmp_seq=2 ttl=64 time=5.977 ms
^C
--- ca.lab ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.511/5.911/6.246/0.304 ms

But when I try to bootstrap my CA, it doesn’t respect my resolver settings:

$ step ca bootstrap --ca-url https://ca.lab --fingerprint xxx
error downloading root certificate: client.Root; client GET https://ca.lab/root/xxx failed: Get "https://ca.lab/root/xxx": dial tcp: lookup ca.lab on 10.20.30.40:53: no such host

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 29 (17 by maintainers)

Commits related to this issue

Incorporate the fix in smallstep/cli#383 — committed to LecrisUT/homebrew-smallstep by LecrisUT 3 years ago
Merge pull request #3 from LecrisUT/patch-1 Incorporate the fix in smallstep/cli#383 — committed to smallstep/homebrew-smallstep by dopey 3 years ago

Most upvoted comments

We’ll be doing another release in the next couple of days, so this should sort itself out.

@maraino can you think of any other reasons not to build our Darwin release packages with CGO enabled?

And why are all the manual tests added as such in the formula? Couldn’t they be included in the makefile as a different test target directly?

I built the homebrew template once a few years ago. At the time, a homebrew maintainer helped me because I had (and still have) no idea what I was doing. The result you see was their recommendation, at the time. If you see anything that can be improved I am very willing to accept PRs. Make a PR to https://github.com/smallstep/homebrew-smallstep, and I’ll make sure it gets incorporated in our next homebrew official PR.

Btw I see other formulas use an if os.mac for CGO so that it does not affect linuxbrew. Maybe it should be implemented as such for consistency.

Sure, shoot us a PR! As you probably know, our team is small and we are mostly focused on feature development. The homebrew stuff is mostly automated so we don’t really think about it anymore. But we’d be mighty grateful if someone with an eye for this stuff took a look at it and made some recommended updates.

dopey on Sep 23, 2021

The fix here, should only affect /etc/resolver and similar redirects. I.e. MacOS uses its own redirect to any setup specified in /etc/resolver before using the standard DNS lookup library that dig or other such tools use. I am not sure about the DHCP advertised names. Those might use a different standard with no proper dns records. The Golang lookup library might not pick those up and/or it might be OS dependent which should be resolved by CGO_ENABLED=1. For insurance, I always setup a proper local DNS server mirroring the DHCP names.

Also some VPNs like ZeroTier would also affect the DNS redirection, but given that your VPN setup seem to pick up the address correctly, it shouldn’t be a problem.

Probably you are just having some DNS/DHCP configuration issues, rather than anything to do with the step program. The long-term fix is very much dependent on the setup, and what you have access to. The best setup would be a local DNS server (authoritative and recursive) which is advertised by the DHCP. Otherwise I have a more complicated setup with /etc/resolver redirects to a local dnsdist that detects which network setup I am on, and sends the requests to the appropriate DNS server.

I have noticed before that macOS Big Sur has an occasional problem with name resolution (nslookup will work, ping won’t).

Remember to clear DNS cache with sudo killall -HUP mDNSResponder.

LecrisUT on Aug 27, 2021

@logopk are you certain it was doing brew install step -s? It should show that the package was not “poured”, but " built from source" or equivalent when you brew info step. You can also edit the formula to confirm that the environment is set, and have Homebrew maintain the temporary files and logs, or manually build with --interactive.

I’m pretty sure that I was using -s, but maybe as it was installed before smth. was left behind.

Now I did it again on top of the 0.16.1 installation and it works as expected. Thanks.

logopk on Aug 27, 2021