I use Pi-hole with Unbound, and Unbound serves a local zone with internal services defined as aliases for my domain.
Since upgrading to Pi-hole v6, I’ve been running into an issue every few hours where accessing an internal service fails with an NXDOMAIN. Running nslookup on the domain confirms the NXDOMAIN, but repeating the query immediately returns the correct IP address.
From the query log, I can see that Pi-hole is returning this because it has cached a NODATA response. Digging further, I observed that Unbound does return a valid A record, but Pi-hole is also querying for an HTTPS (TYPE65) record, which Unbound correctly replies to with NODATA.
It appears Pi-hole is caching the HTTPS NODATA response in a way that interferes with or overrides valid A responses. This becomes a real problem, particularly for local zones where HTTPS records aren’t defined - a single negative response ends up poisoning resolution.
To make matters worse, macOS clients seem to request HTTPS records before A, which makes this behaviour highly visible and disruptive.
I don’t think Pi-hole should cache negative HTTPS responses in a way that affects other record types. It’s unintuitive and leads to avoidable breakage, especially in environments with internal zones.
For anyone else that comes across this issue, I managed to solve it by defining a regex blacklist rule targeting HTTPS records for my domain:
^([a-z0-9-]+\.)*mydomain\.com$;querytype=HTTPS