When a Go program is built without cgo, what handles hostname and user lookups instead of libc?

## Two implementations of the same call Go's standard library contains, for a handful of host-facing lookups, both a Go implementation and one that delegates to the platform's C library. Which one is compiled in is decided at build time by whether cgo is available. Your code is identical either way; only the implementation behind the call changes. The two that matter in practice on Linux are hostname/address resolution in **`net`** and account lookups in **`os/user`**. ## What the pure-Go resolver does The pure-Go path — commonly called the netgo resolver — reimplements what a C resolver does, in Go: - reads `/etc/resolv.conf` to learn the nameservers, the search domains and a subset of the options a C resolver understands; - reads `/etc/hosts` for statically mapped names; - builds and sends DNS queries over UDP, falling back to TCP for truncated answers, and parses the replies itself. Because it is ordinary Go code, a lookup is just another goroutine doing network I/O: it can be cancelled, it does not occupy an OS thread while it waits, and it needs no C library. What it deliberately does **not** do is go through the host's name-service switch. On a glibc system, `/etc/nsswitch.conf` decides the order of sources for hosts and passwd and can name loadable modules — multicast DNS, a container runtime's own name source, a directory-service client. Those modules are shared objects that only the C library knows how to load. Go's resolver never reads that file and never loads those modules, so a name that only such a module can answer becomes unresolvable in a cgo-free build. ## What the pure-Go os/user does The cgo-free `os/user` parses the local account databases directly: `/etc/passwd` for users, `/etc/group` for groups. `user.Lookup`, `user.LookupId` and `user.Current` all work — for accounts that appear in those files. The gap is the same one: accounts that exist only behind the name-service switch, typically supplied by a directory service, are invisible. A C-backed build resolves them because the C library loads the module that queries the directory; the Go implementation only ever sees the file. A related surprise is a root filesystem that has no `/etc/passwd` at all — `user.Current` then has nothing to read and returns an error rather than a user. ## The failure mode this produces The characteristic report is *not* a crash. It is a service that starts cleanly, resolves most things fine, and quietly fails a subset: - one class of hostnames — the ones the local network's name-service module supplies — stops resolving, while public DNS names keep working; - `user.Lookup` returns "unknown user" for accounts that `id` on the same host resolves without trouble; - with no `/etc/resolv.conf` present, *everything* fails, because Go's resolver falls back to localhost nameservers and nothing is listening there. All three are behavioural differences between two implementations of the same API, which is why they survive a code review of the diff: the diff is in the build, not in the source. ## Why the swap is usually still worth it The pure-Go path buys a binary with no run-time C library dependency, which is what makes one artefact runnable on any host of the right architecture. It also makes name resolution behave the same everywhere, which is a genuine operational virtue: the resolver you tested is the resolver that runs, rather than whatever the deployment host's C library and modules happen to do. The cost is fidelity to the host's configuration. If the environment's naming really is defined by name-service modules or its accounts really do live in a directory, then a cgo-free build is not "the same program, statically linked" — it is a program that sees a smaller world. ## How to work around the gap without going back to cgo When only a small part of the lost behaviour matters, there are usually cheaper options than re-linking the C library: - ship the entries that matter into the runtime filesystem — a `/etc/hosts` line, a `/etc/passwd` entry for the account the process runs as, a `/etc/resolv.conf` pointing at the real nameservers; - query the authoritative source yourself over its own protocol instead of through the name-service switch; - keep the numeric identity: if the code only needs a uid to compare against, it may not need `os/user` at all. Each of those keeps the portable artefact and pays for the one behaviour you actually depend on, which is nearly always a better trade than restoring a C library dependency for the whole binary.