A service resolves hostnames correctly on a Debian host but misbehaves on Alpine Linux: an entry added to `/etc/nsswitch.conf` has no effect, and a lookup returning a large answer fails. How does musl's resolver differ from glibc's, and what does that mean operationally?

## Two different designs, not a bug Name resolution on Linux is not a kernel service. `getaddrinfo` is a libc function, so what happens when a program resolves a hostname depends entirely on which libc it is linked against. glibc and musl made opposite architectural choices here, and every Alpine DNS surprise follows from that. ## glibc: pluggable by design glibc routes host, user and group lookups through the **Name Service Switch**. `/etc/nsswitch.conf` lists, per database, the sources to consult in order — `hosts: files dns` being the common case — and each named source corresponds to a shared object that glibc loads at run time. That is how a host gets users from LDAP or SSSD, hostnames from mDNS, or a local caching daemon in the path, without any application knowing. ## musl: one resolver, no plugins musl rejects that model. Loading arbitrary shared objects into every process that resolves a name conflicts with musl's goals around static linking, size and predictability. So musl has no NSS at all: `/etc/nsswitch.conf` is not parsed, not warned about, just ignored. Host lookup is fixed as `/etc/hosts` first, then DNS using the nameservers in `/etc/resolv.conf`. The operational consequence is that an entire category of configuration becomes a no-op. Directory-backed users and groups, mDNS names, and plugin-based caching do not work on Alpine, and nothing tells you — the file is present, your edit is in it, and it means nothing. On a system that was expected to join a corporate directory, that is a design constraint, not a tunable. ## Parallel queries instead of ordered fallback Given several `nameserver` lines, glibc contacts the first and moves to the next on timeout or failure, so an ordering in `resolv.conf` is a genuine preference. musl sends the query to all listed nameservers at once and uses the first usable reply. It is faster and more resilient when a resolver is down — no waiting out a timeout — but it discards the notion of a primary. If your second nameserver serves a split-horizon or stale view, musl will sometimes return that view purely because it answered first, producing intermittent, host-dependent wrong answers that look like caching but are not. musl also issues the A and AAAA queries concurrently. Correct resolvers cope; some older middleboxes and load balancers handle two outstanding queries poorly and drop one, which shows up as sporadic resolution failures on Alpine only. ## Truncation and TCP fallback A UDP DNS response that does not fit sets the TC (truncated) bit, and the client is expected to retry over TCP. musl did not implement that fallback until version 1.2.4, released in 2023 and shipped by Alpine releases from that year onward. On an older Alpine, a name whose answer set is large — a service with many addresses, or a record carrying a lot of data — fails to resolve while the identical query succeeds from a glibc host on the same network. Check what you are actually running before theorising: ``` apk info -v musl /lib/ld-musl-x86_64.so.1 # prints the musl version banner ``` ## What is not different Two things worth stating so you do not chase them. First, neither libc caches DNS answers on its own — a plain glibc host without a caching daemon re-queries just like musl does, so 'Alpine has no DNS cache' is not a distinction. Second, `/etc/resolv.conf` itself is read by both, and both honour `nameserver` and search-domain configuration; the divergence is in the strategy applied to that configuration, not in the file's location or basic syntax. ## How to diagnose Work out which layer is answering. Comparing a lookup from a resolver tool against what the application sees is misleading here, because a standalone DNS tool talks to the network directly while the application goes through libc — that gap is exactly where an NSS-versus-musl difference hides. Reproduce with a small program that calls `getaddrinfo` on the affected host, capture traffic to see whether queries go out in parallel and whether a truncated reply came back, and check the musl version before assuming a behaviour is present. If the requirement is genuinely directory integration or a plugin-based name source, the honest conclusion is that the workload does not belong on a musl system. ## Why this is a senior question It is only answerable if you know that name resolution lives in libc rather than the kernel, that a distribution's libc choice therefore changes application behaviour, and that a configuration file can be present and completely inert. Those are the instincts that let someone debug a machine they did not build.