[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260823214211.GM23438@brightrain.aerifal.cx>
Date: Sun, 23 Aug 2026 17:42:11 -0400
From: Rich Felker <dalias@...c.org>
To: Junior Botelho <junowerther@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: getaddrinfo(AF_UNSPEC) fails entirely on NXDOMAIN for one of A/AAAA, even when the other succeeds — real-world impact via Pi-hole
On Sun, Aug 23, 2026 at 10:38:11AM -0300, Junior Botelho wrote:
> 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").
As you've noted, this behavior is intentional, and it looks like we've
gotten almost all of the offending server implementations fixed at
this point. The focus really should be on getting the few stragglers
to do the same.
It's been a while since I've looked at this specific case, so I'd have
to think through whether failure is a hard requirement here. I don't
think treating the NxDomain as if it were NODATA here would admit ways
to spoof results. What it would do is (1) cut off a possible
optimization we seems to be missing now, of returning as soon as a
single NxDomain is seen, without waiting for the other one, and (2)
make the results with AF_UNSPEC inconsistent with the results with
AF_INET6. But right now they're already inconsistent with the results
with AF_INET specified. The only way to fix that is by always doing
both queries, regardless of what the caller requests, just to validate
that they match.
Please continue to pursue getting pi-hole to fix this, since that
should be done regardless of whatever changes might be possible in
musl.
Rich
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.
