Local DNS record occasionally mixed with stale cache A-record in response (FTL v6.6.2)

[hallerla]

Versions

• Pi-hole: v6.4.2
• Web: v6.5.1
• FTL: v6.6.2

Platform

• Platform: Raspberry Pi

Expected behavior

When a Local DNS record exists for a queried domain, Pi-hole should return only the configured Local DNS response and completely suppress any cached or stale upstream A/AAAA records for that domain.
The response should not contain multiple A records combining Local DNS results and cached/stale upstream results.
A restart of the DNS service should not be required to ensure correct prioritization of Local DNS records over cached or stale responses.

Actual behavior / bug

possible cache/stale interaction issue
When querying a domain with a Local DNS Record defined, the response occasionally contains both:

• the Local DNS A record
• an additional stale/cached A record from upstream resolution

Example:
Local DNS:
connectivitycheck.gstatic.com → 46.38.242.112

Observed response:

46.38.242.112
142.251.110.94

dig output:
connectivitycheck.gstatic.com. 0 IN A 46.38.242.112
connectivitycheck.gstatic.com. 0 IN A 142.251.110.94

After restarting pihole-FTL service, only the Local DNS record is returned correctly.
This behavior disappears after cache reset via service restart.

Steps to reproduce

1. Add Local DNS record for a frequently queried domain
2. Trigger queries from client (Android connectivity check works well)
3. Observe mixed A records in response
4. Restart pihole-FTL
5. Observe correct single Local DNS response

Debug Token

After restart of FTL, no debug was done since behavior was already correct.

Screenshots

Pi-Hole Tail-Log captured while error occured, before restart of Pi-Hole:
2026-06-19 02:07:37.176 query[A] connectivitycheck.gstatic.com from 192.168.0.113
2026-06-19 02:07:37.176 /etc/pihole/hosts/custom.list connectivitycheck.gstatic.com is 46.38.242.112
2026-06-19 02:07:37.177 cached-stale connectivitycheck.gstatic.com is 142.251.110.94
2026-06-19 02:07:37.178 forwarded connectivitycheck.gstatic.com to 192.168.0.254
2026-06-19 02:07:37.209 reply connectivitycheck.gstatic.com is 142.251.110.94

Notes
Issue appears intermittently and is dependent on cache state
Behavior resolves after restarting pihole-FTL
Likely related to interaction between Local DNS resolution and serve-stale/cache response handling
Upstream resolver via router / external DNS (FritzBox / DoT environment)
Client: Android device (connectivity check trigger)

[DL6ER]

Thanks for the detailed report - the tail log made this easy to track down, and I can confirm it is a genuine bug.

It is not Pi-hole specific: it is an issue in dnsmasq's answer handling, which I reproduced with plain upstream dnsmasq. The chain of events is:

1. The domain gets resolved upstream and cached (here 142.251.110.94) before the Local DNS record exists.
2. You add the Local DNS record. FTL rewrites custom.list and dnsmasq reloads only that file (via inotify); the rest of the cache is not flushed, so the old upstream entry stays.
3. With the query cache optimizer (dns.cache.optimizer, dnsmasq's serve-stale, on by default), that upstream entry lingers as cached-stale after its TTL expires.
4. When both a local record and a cached/stale upstream record exist for the same name, dnsmasq returns both, and the stale entry also triggers the "forwarded" refresh you saw.

A pihole-FTL restart flushes the whole cache, so the leftover upstream record is gone and only the local record remains - which is exactly what you observed.

I have written a fix for dnsmasq: once a name has an authoritative local record, its cached upstream records are no longer mixed into the reply and no longer trigger a stale refresh. I confirmed it resolves the reproducer, and the patch has already been sent upstream to the dnsmasq mailing list. We will carry it in FTL until it is merged there.

In the meantime you can avoid it by disabling the optimizer:

pihole-FTL --config dns.cache.optimizer -1

then restart FTL once to clear the current cache. Note this narrows the window a lot but is not a complete fix on its own - within an already-cached domain's normal TTL you could still briefly see both answers until that entry expires. The dnsmasq fix above is the proper resolution.

[hallerla]

Thanks for picking this up. Not a big issue at all, just wanted to share, since I came across this. And maybe a short note. I wanted to change the connectivitycheck to go through Kuketz rather than Google, thus the IP address 46.38.242.112. Such a wonderful and mighty piece of Software.
Tausend Dank.