FTL returns NXDOMAIN (not NOERROR) for AAAA queries on local A-only domains — breaks musl-based getaddrinfo(AF_UNSPEC) clients

[juniorbotelho]

Versions

• Pi-hole: v6.4.3 (Latest: v6.4.3)
• Web: v6.6 (Latest: v6.6)
• FTL: v6.7 (Latest: v6.7)

Platform

• OS and version: Ubuntu 26.04 LTS (Resolute Raccoon) x86_64
• Platform: Podman rootless container (Pi-hole itself), client under test also Podman rootless

Expected behavior

A domain that only has a local A record (configured via wildcard, e.g. address=/lua.lan/10.0.0.3 in /etc/pihole/dnsmasq.d/) should return NOERROR with an empty answer section when queried for AAAA. Per RFC 2308 §2.2, "No Data" (name exists, but not for the queried type) is a distinct condition from NXDOMAIN (name does not exist at all), and must be signaled as NOERROR with no relevant records in the answer section — not NXDOMAIN. Public resolvers I compared against (Cloudflare 1.1.1.2) return NOERROR correctly for domains they serve that similarly lack AAAA.

Actual behavior / bug

FTL returns NXDOMAIN for AAAA queries against a domain that has a valid local A record. Log evidence from pihole -t:

09:17:15: query[AAAA] forgejo.lua.lan from 10.89.4.10
09:17:15: config forgejo.lua.lan is NXDOMAIN

Note the config keyword — this confirms FTL is generating this response itself from the local configuration, not forwarding to and receiving it from an upstream resolver.

This has real downstream impact: any client using musl libc's getaddrinfo() with AF_UNSPEC (the default for most dual-stack-aware programs, e.g. ssh, various Alpine-based container tooling) treats a NXDOMAIN response to either the A or AAAA sub-query as a total resolution failure — even when the other sub-query succeeded. This is documented musl behavior/known discrepancy vs. glibc (see the musl mailing list thread "getaddrinfo() fails for domains with no AAAA records", and a similar report in netbirdio/netbird#2098). So while musl's behavior might also be worth reconsidering, the FTL response here isn't RFC-compliant regardless, and fixing it would sidestep the musl issue entirely for anyone in a similar setup.

Steps to reproduce

1. Configure a local wildcard/custom DNS record with only an A record, e.g. address=/example.lan/10.0.0.3
2. dig AAAA example.lan @<pihole-ip> +noall +comments +answer
3. Observe status: NXDOMAIN, ANSWER: 0

Comparison against a public resolver for a domain that also lacks AAAA:

$ dig AAAA github.com @1.1.1.2 +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51466
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

vs.

$ dig AAAA forgejo.lua.lan @10.0.0.3 +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15334
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Three-way comparison, same client, same server for query 3:

1. AAAA github.com @1.1.1.2 (Cloudflare, authoritative-ish upstream)
   → NOERROR, ANSWER: 0, AUTHORITY: 1

2. AAAA github.com @10.0.0.3 (my Pi-hole, forwarding to upstream)
   → NOERROR, ANSWER: 0, AUTHORITY: 1 (correctly forwarded/relayed)

3. AAAA forgejo.lua.lan @10.0.0.3 (my Pi-hole, answering locally from config)
   → NXDOMAIN, ANSWER: 0, AUTHORITY: 0

This confirms FTL's forwarding path handles AAAA-absent responses correctly
(matches upstream behavior exactly). The bug is isolated specifically to the
local-config-answer path (wildcard/custom DNS records), not to FTL's general
DNS handling.

Debug Token

• URL: https://tricorder.pi-hole.net/GMd8Kdt5/

Screenshots

Additional context

This looks related to (but distinct from) #2561 ("Local records: Ignored for AAAA requests"), which describes AAAA queries for local records being incorrectly forwarded upstream. In my case, FTL isn't forwarding — it's directly answering NXDOMAIN from config. Possibly the same underlying local-record lookup path, different failure mode depending on configuration (wildcard vs. exact host record?). Happy to test variations if useful.

Suggested fix

When a queried name has a local A record but no local AAAA record (and vice-versa), FTL should synthesize a NOERROR/empty-answer (NODATA) response for the missing type, rather than falling through to NXDOMAIN. This mirrors what public resolvers already do and is required by RFC 2308 §2.2.

[DL6ER]

Thanks, this reproduces exactly as described, and your reading is right: the NXDOMAIN is generated locally, not relayed.

Two config lines combine here. Pi-hole writes local=/lan/ for the configured DNS domain, which makes us authoritative for .lan, while your address=/lua.lan/10.0.0.3 sits in a more specific domain. The AAAA query finds no answer in the more specific one, falls back to the local=, and gets NXDOMAIN - for a name dnsmasq resolves for A one query earlier.

That decision is made in dnsmasq's is_local_answer(), so the fix belongs upstream. We have sent a patch to dnsmasq-discuss.

Until it lands, pairing your address= with a matching local= gives you NODATA:

local=/lua.lan/
address=/lua.lan/10.0.0.3

This is different from #2561, where the query really is forwarded.

[juniorbotelho]

Adding the matching local= line fixes it on my end:

local=/lua.lan/
address=/lua.lan/10.0.0.3

Before:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49451
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

After:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 581
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Thanks for tracking this down to is_local_answer() and for looping in dnsmasq-discuss, appreciate the quick and thorough response.

Happy to test any further patches against my setup if useful, and will report back on the Dev Containers side (microsoft/vscode-remote-release#11806) that this is resolved at the source for anyone hitting the same combination.

[DL6ER]

Some background worth adding. The local= pairing you tested is the documented remedy rather than something I improvised: man dnsmasq notes that the behavior for queries not matching the address literal changed in 2.86, and gives --address=/example.com/1.2.3.4 --local=/example.com/ to restore the NoData answer. It came up on dnsmasq-discuss in March 2024 as well.

What the manual assumes is a local= for the same domain as the address=. You already had one for the parent, local=/lan/, which Pi-hole writes for the configured DNS domain, and that is the case it does not cover: being authoritative for the parent turns the answer into NXDOMAIN, and the way out is a second, more specific local= that nothing tells you to add. That is what the patch changes.

[juniorbotelho]

Good to know this traces back to a documented (if easy-to-miss) behavior. Appreciate you digging into the parent/child local= interaction. If a patch does land to improve this behavior, it'd be very welcome.