[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFqgDTEQs4s5rYVM0Zuumd=J7ku6PU8x7TpzteAYWvoap+EMuA@mail.gmail.com>
Date: Sun, 23 Aug 2026 10:38:11 -0300
From: Junior Botelho <junowerther@...il.com>
To: musl@...ts.openwall.com
Subject: getaddrinfo(AF_UNSPEC) fails entirely on NXDOMAIN for one of A/AAAA, even when the other succeeds — real-world impact via Pi-hole
Hi,
I ran into the behavior discussed in this 2021 thread ("getaddrinfo()
fails for domains with no AAAA records (regression?)",
https://www.openwall.com/lists/musl/2021/07/19/8) and wanted to add a
concrete real-world case, since it's still current behavior and causes
a fairly confusing failure mode for end users.
Setup: Alpine 3.20 container (musl, current as of the base image
mcr.microsoft.com/devcontainers/base:0-alpine-3.20), resolving a name
against a local DNS server (Pi-hole/FTL) that has a valid A record but
incorrectly answers the AAAA query with NXDOMAIN instead of
NOERROR/empty-answer. I've filed that as a Pi-hole bug separately
(https://github.com/pi-hole/FTL/issues/3039), since RFC 2308 §2.2 is
clear that this is a NODATA condition, not NXDOMAIN. But it's a real,
if non-compliant, resolver behavior that apparently isn't rare in
home-lab/self-hosted DNS setups.
Minimal repro (C, AF_UNSPEC, no special flags):
struct addrinfo hints = {0}, *res;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
int status = getaddrinfo("forgejo.lua.lan", NULL, &hints, &res);
// status == EAI_NONAME (-2), even though the A record resolves fine
For comparison, the same binary against github.com (which also lacks
AAAA, but is served by a resolver that correctly returns NOERROR for
the AAAA query) succeeds and returns the A record:
getaddrinfo SUCCESS:
family=2
`getent hosts` (not AF_UNSPEC) resolves the A record correctly in both
cases. Only the AF_UNSPEC/getaddrinfo path fails, and only when the
upstream resolver returns NXDOMAIN instead of NOERROR for the missing
type. A third comparison, querying github.com through the same Pi-hole
(which forwards correctly and returns NOERROR, matching upstream)
confirms the resolver's forwarding path is fine — the NXDOMAIN is
specific to Pi-hole's local-record answer path, isolating the
non-compliant behavior to that one code path on their end.
This matches the description in netbirdio/netbird#2098
(https://github.com/netbirdio/netbird/issues/2098), filed against a
different DNS server with the same non-compliant AAAA behavior, same
musl-specific symptom.
I understand from the 2021 thread that this may be considered
intentional/by-design (treating any NXDOMAIN in a dual-stack lookup as
fatal), and that the "correct" fix is arguably on the resolver side —
which is exactly what I'm pursuing with the Pi-hole report above. But
given at least two independent real-world DNS server implementations
exhibiting this exact non-compliant AAAA behavior, I wanted to ask:
would musl consider a defensive change here — e.g. returning success
with the address family that did resolve when the other sub-query
fails with NXDOMAIN, rather than failing the whole call? This would
bring behavior closer to glibc's, which reportedly does not have this
failure mode, and would make musl-based programs (ssh, git, various
Alpine-based container tooling) noticeably more robust against
non-compliant resolvers in the wild, at what seems like a fairly
contained risk (a name that has at least one valid record type
shouldn't resolve as "doesn't exist").
Happy to provide the full test program, strace output, or test against
a specific patch if that would help move this forward.
Thanks,
Junior Botelho
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
