What is the reason behind `CGO_ENABLED=0`?

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](https://golang.org/pkg/net/#hdr-Name_Resolution).

### 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)?

Start by reviewing the Go build configuration or release entry point that sets CGO_ENABLED=0, then compare it with Go's net package name-resolution behavior and the macOS VPN case described here. Done means documenting why the static build is used and whether the build or resolver behavior should change; the issue provides no file or test names.

Written by the indexing model from the issue text.