What is the reason behind CGO_ENABLED=0?

[bazhenov]

I've facing problems using kubectl-debug with k8s cluster deployed in intranet. It boils down to kubectl-debug built with CGO_ENABLED=0 which disables host bases DNS-resolver.

Description of the problem

MacOS DNS resolver quite sophisticated (libc function gethostbyname()). It takes in consideration scoped DNS queries when connected over VPN. My workplace VPN has DNS zone .kube.private and macOS sends all *.kube.private DNS-queries to the VPN DNS server, not my ISP-provider one. But CGO_ENABLED=0 disables cgo and linking over libc, and there is no chance go-native DNS resolver will ever implement all the logic of macOS DNS resolver.

So, in the end I have somewhat frustrating somewhat funny behaviour – kubectl-debug says no such host, but I can ping it:

$ kubectl-debug search-sessions-backend-9b85975c4-xvrkr
Unable to connect to the server: dial tcp: lookup api.kube.private. on 192.168.1.1:53: no such host
$ ping api.kube.private.
PING api.kube.private (80.92.164.106): 56 data bytes
64 bytes from 80.92.164.106: icmp_seq=0 ttl=56 time=119.965 ms
...

I'm interested what are the reasons for using CGO_ENABLED=0? Does static linking so bad after all (at least under macOS)?