Here's the code that determines if it needs to fall back to cgo: https://github.com/golang/go/blob/161874da2ab6d5372043a1f3938a81a19d1165ad/src/net/conf.go#L122

Here's the code that determines if it needs to fall back to cgo: https://github.com/golang/go/blob/161874da2ab6d5372043a1f3938a81a19d1165ad/src/net/conf.go#L122-L280 https://github.com/golang/go/blob/161874da2ab6d5372043a1f393... Notably, it can only handle the following sources: files, dns, myhostname, mdns* (but only a subset of those if you read the gory details). It doesn't handle the fairly uncommon "mymachines" or "resolve" (sometimes used in the systemd world nowadays) I probably spoke too pessimistically there. Many machines won't have an nsswitch.conf that requires using cgo for common domains. After re-reading the code, it does handle more than I thought (mainly mdns). > I would kinda hope that modern and generally useful features would be in netgo. And old rotted code, security risks and anachronisms would be abandoned The fundamental problem here is not that. The nss system libc uses for network resolution is a pluggable system, and it chose dynamically linked c modules as its plugins. It's not that they're old rotted insecure bits of code, it's that the interface is inherently a c-centric one, and go early on decided it wished to do syscalls directly instead of call them through libc (as literally every other programming language does). Finally, that means go can't ever reach full parity as long as it wishes to avoid c, since anyone can simply write a new nss plugin in c and list it in resolv.conf, and go has no way of having that same arbitrary behaviour in go.