Domains added in Domain management Denay list, is not being blocked after latest Pi-Hole update

[souvikranju]

Versions

Core version is v6.4.2 (Latest: v6.4.2)
Web version is v6.5 (Latest: v6.5)
FTL version is v6.6.2 (Latest: v6.6.2)

Platform

• OS and version:
  NAME="Debian GNU/Linux"
  VERSION_ID="13"
  VERSION="13 (trixie)"
  VERSION_CODENAME=trixie
  DEBIAN_VERSION_FULL=13.5
• Platform: RPI 3B+, bare-metal

Background

I had setup my Pi-Hole to block some specific domains for a particular device. This is how I achieved that goal:

• A separate group other than the default group
• A client with MAC id - Assigned groups: default and my custom group
• Domains
  Specific domains assigned to the custom group. Type - Exact deny

Expected behavior

When the specific client tries to query the domains added in the Domain management, Pi-Hole should block the domain. This behavior was applicable until last Pi-Hole update.

Actual behavior / bug

The specific client is able to resolve all the domains added in the domain management. I see the domain entries in the Pi-Hole log itself as resolved. Whereas queries from the old disk data shows that the same domain was being blocked.

Steps to reproduce

No specific step required. I can observe from the client behavior that the client was able to resolve blocked domains and Pi-Hole query logs confirms the same.

Debug Token

Not generating right now - if the issue is not reproducible, I will generate the debug log.

Screenshots

• Group list

• Client

• Domain

• Recent query log

• Expected behavior, showing an old query, before the last update:

[yubiuser]

Please generate a debug token.

[souvikranju]

Debug token: https://tricorder.pi-hole.net/k07jAguQ/

[souvikranju]

I suspected that the Client has updated the MAC ID, due to which, Pihole MAC specific actions are not being triggered. I ran the following to view the MAC of a device as seen by Pihole, over last 30 days:

DEVICE_NAME="SetTopBox-9215.lan"
DAYS=30
DB="/etc/pihole/pihole-FTL.db"

sudo pihole-FTL sqlite3 -readonly "$DB" "
SELECT DISTINCT
  n.hwaddr AS mac
FROM network_addresses na
JOIN network n ON n.id = na.network_id
WHERE na.name = '$DEVICE_NAME'
  AND na.lastSeen >= strftime('%s','now','-$DAYS days')
  AND n.hwaddr IS NOT NULL AND n.hwaddr != ''
ORDER BY mac;
"

The output was a single MAC - the same configured in pihole

[souvikranju]

This is interesting issue, I think. From the query log, I see all the queries to a blocked domain, were being blocked properly before 17th May. But after 17th May, the blocking was triggered only twice - even though the IP of the client didn't change:

I tried to reproduce the issue by adding another device to the same group - but query from the test device is being blocked properly by Pihole as it should:

dig mercury.akamaized.net "@pi.hole"

; <<>> DiG 9.17.12 <<>> mercury.akamaized.net @pi.hole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50621
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (denylist)
;; QUESTION SECTION:
;mercury.akamaized.net.         IN      A

;; ANSWER SECTION:
mercury.akamaized.net.  2       IN      A       0.0.0.0

;; Query time: 5 msec
;; SERVER: 192.168.29.100#53(pi.hole) (UDP)
;; WHEN: Mon May 25 20:58:25 India Standard Time 2026
;; MSG SIZE  rcvd: 80

[yubiuser]

I had a look at your debug log and saw no issue regarding the group configuration. Your query log screenshot would suggest something happened between 17th and 19th of May - was this when you updated your Pi-hole? From which version did you upgrade? It's even stranger that it was successfully blocked after 19th of May.

I think the last time the relevant code was touched was in #2791

Does the blocking work reliably when you specify it by IP?

[rdwebdesign]

How does the device appears on the Tools > Network page?

Do you see more than one IP for that MAC? more than one device using the same name?

[souvikranju]

Thanks for looking into this issue.

I don’t remember the exact date when I updated Pi-hole, so please bear with the detailed timeline below.

Sequence of events

1. I initially noticed ads showing up on a specific device where those domains should have been blocked by Pi-hole.

2. To investigate, I checked the Pi-hole admin panel. The query logs confirmed that the domains were not blocked on May 19 and May 23.

   • I tried to recall any recent changes w.r.t. Pi-Hole and could only think of:
     • Updating the Raspberry Pi OS
     • Updating Pi-hole
   • I’m certain that I did not change any Pi-hole configuration.
   • Based on this, I opened this GitHub issue.

3. Regarding your question:

   Does the blocking work reliably when you specify it by IP?

   I powered the client device back on again on May 25, and surprisingly, Pi-hole started blocking domains correctly again.

   • I did not change the client to IP-based detection.

• Prior to this (for testing purposes), I had:
  • Added another device to the same group
  • Performed DNS queries (blocking worked as expected)
  • Removed the test device grom the group afterward

Version / update details

• I recall that Pi-hole Web was already up to date.
• Most likely:
  • Core: upgraded from 6.4.1
  • FTL: upgraded from 6.6 or 6.6.1

I don’t remember the exact update date, but I ran a command (suggested by an LLM) to inspect APT history:

apt-get -qq --no-install-recommends install /tmp/pihole-meta.deb
Requested-By: pi (1000)
Upgrade: pihole-meta:arm64 (0.6, 0.7)
End-Date: 2026-05-16 21:54:44

This suggests the update happened on May 16, 2026.

However:

• Blocking worked correctly on May 17
• Blocking failed on May 19 and May 23
• Blocking started working again on May 25

So the behavior changed without any further updates or configuration changes.

If there’s a more reliable way to determine the exact Pi-hole/FTL update timing, please let me know.

Additional observations

How does the device appears on the Tools > Network page?

• On Tools → Network, I see only a single entry for the device (no duplicate IPs or names).

• FTL reports:

  FTL: PID 724, last restart was on Sunday, May 17th 2026, 10:05:43
  

This suggests that within the same FTL runtime, all three states occurred:

• Blocking working
• Blocking not working
• Blocking working again

At this point, I’m unsure how to further investigate, given that the issue resolved itself but was reproducible for at least two days.

[yubiuser]

I think we need to investigate further when the issue re-appears. We're likely unable to trace it back >3 days now.