Local host overrides for public domain intermittently ignored with DNSSEC enabled, clients receive upstream NXDOMAIN instead of local answer

[old-square-eyes]

Versions

• Pi-hole: v6.4.1
• Web: v6.5
• FTL: v6.6

Platform

• OS and version: Debian-based Linux on multiple hosts

• Platform: Native installs on multiple LAN hosts / VMs

Expected behavior

A hostname configured as a local Pi-hole override should be answered locally every time, regardless of which LAN client asks the question.

If a local host record exists for a name under a public domain, Pi-hole should return the configured local A record instead of falling through to upstream/public recursion. In short, the override should actually override.

Related issues:

• DNS returns NXDOMAIN on entries from dnsmasq
• Local addresses defined in dnsmasq config return NXDOMAIN
• Pi-Hole v6 not resolving names for LAN devices after upgrade

Actual behavior / bug

The same Pi-hole server returns different answers for the same locally configured hostname depending on which client asks.

For the same query name and same Pi-hole IP:

• querying from the Pi-hole host itself returns NOERROR with the configured local A record
• querying from another Linux LAN client returns NXDOMAIN with the public authoritative SOA for the parent domain

This should not happen for a local host override.

Important context: this setup worked until a few weeks ago, and the breakage appears to line up with recent Pi-hole v6-era behavior changes around local DNS / local-domain handling. Similar reports describe local DNS records or split-DNS forwarding working before upgrade and failing afterward:

• Local DNS Records not working anymore after updating to v6
• Pihole not forwarding local domain after update to V6
• Local DNS records not resolving - Beta 6.0

I initially suspected DNSSEC because disabling DNSSEC made some cases start working again, but the client-dependent behavior still reproduces even after:

• setting dns.domain.name = ""
• setting dns.dnssec = false
• setting dns.localise = false

Steps to reproduce

Steps to reproduce the behavior:

1. Configure local host overrides in Pi-hole for names under a public domain, for example:
   • host-a.example.test -> 10.0.10.10
   • node-1.lab.example.test -> 10.0.20.20
2. Confirm the records exist in FTL config under dns.hosts.
3. From the Pi-hole host itself, query the Pi-hole LAN IP:
   • dig @10.0.20.53 node-1.lab.example.test
4. Observe NOERROR with the configured local A record.
5. From another Linux client on the LAN, query the same Pi-hole IP for the same name:
   • dig @10.0.20.53 node-1.lab.example.test
6. Observe NXDOMAIN with the public SOA for example.test instead of the local A record.

Optional additional attempts that did not resolve the issue:

1. Disable DNSSEC
2. Set dns.domain.name to an empty string
3. Set dns.localise to false
4. Restart pihole-FTL
5. Repeat the same tests
6. Observe that the same client-dependent mismatch can still occur

References:

• Pi-hole FTL configuration
• DNSSEC validation and local domains
• Understanding DNSSEC validation using Pi-hole's Query Log

Debug Token

• URL: Please replace with your pihole -d upload token

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

This was reproduced across multiple Pi-hole instances configured as LAN DNS servers.

The local records were present in pihole-FTL --config under dns.hosts, so this does not appear to be a missing-record problem. Pi-hole’s FTL config docs describe these as local host mappings managed by FTL:

• Pi-hole FTL configuration

Behavior differed between clients:

• macOS with Firefox appeared to continue working
• Linux clients, including Home Assistant OS and another Linux machine, hit the failing path

The strongest evidence is that the same Pi-hole server returned different results for the same query at nearly the same time:

From the Pi-hole host:

dig @10.0.20.53 node-1.lab.example.test
-> NOERROR
-> ANSWER SECTION: node-1.lab.example.test. 0 IN A 10.0.20.20

From another Linux client:

dig @10.0.20.53 node-1.lab.example.test
-> NXDOMAIN
-> AUTHORITY SECTION: example.test. IN SOA <public authoritative SOA>

This makes it look like Pi-hole/FTL is varying behavior by client/query path, or incorrectly bypassing local host overrides for some clients. Recent v6 reports about local entries returning NXDOMAIN unexpectedly seem related.

[DL6ER]

Thanks for the detailed report - working through this was quite some task but I can now that this is a valid bug in dnsmasq, not specific to Pi-hole.

Root cause

There are two gaps in how dnsmasq handles locally-configured hostnames (from /etc/hosts, DHCP leases, or Pi-hole's dns.hosts / custom.list):

1. Missing NODATA fallback for unsupported query types

When a client queries a locally-configured hostname for a record type that has no local answer, e.g. AAAA when only an A host record is configured, or HTTPS/SVCB which modern Linux resolvers send, answer_request() returns "can't answer" and the query is forwarded upstream. Since the domain only exists locally, the upstream authoritative server returns NXDOMAIN ("this domain does not exist"), which is factually wrong: the domain does exist, just not for the requested record type. The correct answer would be NODATA.

This explains the client-dependent behavior: Linux resolvers (like systemd-resolved) routinely send AAAA alongside A queries (type-65 (HTTPS) queries). macOS may not send these additional types, or handle them differently, I am not familiar with Apple devices. When the AAAA/HTTPS query gets forwarded and receives NXDOMAIN, that response can reach the client before or alongside the correct A answer, causing (semi-)permanent resolution failures.

2. DNSSEC BOGUS answers bypass the safety net

dnsmasq already has a safety net: when an upstream NXDOMAIN comes back for a locally-known domain, it converts the response to NODATA. However, this conversion is gated behind !bogusanswer, it is skipped when DNSSEC validation fails. For locally-configured hostnames under publicly-signed domains, the upstream NXDOMAIN proof can fail DNSSEC validation (since the domain's local existence contradicts the upstream's signed denial), causing the safety net to be bypassed entirely. This explains why disabling DNSSEC helped some cases.

Fix

Both issues above need to be fixed:

1. answer_request(): Before returning "can't answer," check whether the domain has any local record (F_HOSTS/F_DHCP/F_CONFIG). If so, return NODATA instead of forwarding — the domain exists locally, it just doesn't have the requested record type.

2. process_reply(): Move the NXDOMAIN-to-NODATA conversion for locally-known domains before the DNSSEC bogus-answer gate. Local host records are authoritative for domain existence regardless of upstream DNSSEC status.

Both issues exist in upstream dnsmasq (not caused by any Pi-hole extensions), so a patch has been submitted upstream. We'll import the fix into our fork once it's accepted but not earlier as further changes may be made to it. Thank you very much for reporting!

[old-square-eyes]

Thanks for the investigation. Do you have a link to the dnsmasq PR / Issue?

In the meantime is there a downdrade rollback step I can take? All my local webservers have been unusable for nearly 2 weeks (without major reconfig to use IP, then I have issues with certs).

[DL6ER]

I sent the patch to Simon Kelley and the dnsmasq-discuss mailing list. The workflow is to await relies now. What is quite suspicious is that neither my mail is showing up in the archives not has there been any mail for over a month now which - to me - seems to suggest the mailing list is broken (there is never such long silence). My mail should have gone though to Simon though and I will resend it to him in roughly one month (I typically let two months pass between resubmissions).

Downgrading is, unfortunately, not officially supported, easiest would be using the docker container with a suitbale tag for this, you could also try

sudo pihole checkout ftl v6.4

or similar but no warranty that this will work in-place nicely. Please make sure to at least backup your config files before trying this.