Group Management - Creating a group with no blocking doesn't work

Expected Behaviour:

Using Pi-hole group management I want to create groups that have certain domains whitelisted. I just started with creating a group that has no blocklists applied to it called ads.
I've set two devices to have static ip addresses as clients for this test group.

  • pi-hole info:
    Pi-hole version is v5.2.2 (Latest: v5.2.2)
    AdminLTE version is v5.2.2 (Latest: v5.2.2)
    FTL version is v5.3.4 (Latest: v5.3.4)
  • raspberry pi zero w

Note my router setup is using an eero system with the DHCP left to the eero. I've set the primary IPV4 DNS server to my Pi-hole and everything else has been functioning perfectly in terms of blocking.

Actual Behaviour:

My group with no blocking isn't working at all.

The ads group doesn't seem to behave any differently in any way. All of the pi-hole blocklists are still being applied from what I can tell. I've done a variety of restarting and rebooting to absolutely no avail.




Debug Token:

Debug token:

In your query log or dnsmasq log (/var/log/pihole.log), do you see queries to Pi-hole from those clients?

From the Mac terminal (and not via ssh to the Pi) what is the output of


I ran tests on these two clients in the ads group, where I would open up the log using pihole -t and then go to a website with lots of ads. The query log would quickly fill up with requests from their respective ip addresses, but it seemed they were still being blocked by gravity.

I thought perhaps this was an issue with the router ip being the only one making requests, but the query log does show these device IPs. The client IPs are grayed out compared to the white of the IP requests from the router. Possibly an issue with an eero mesh setup?

It kind of seems there is some forwarding going on.

Reference on the color coding in the terminal:

White being the router IP, red being blocks, and gray being forwarding / responses / IP of the client.

Actual example from log:

Jan  4 04:59:04: query[A] from *Router ip*
Jan  4 04:59:04: gravity blocked is
Jan  4 04:59:04: query[type=65] from *Router ip*
Jan  4 04:59:04: gravity blocked is
Jan  4 04:59:04: query[type=65] from *One of the Client's ip*
Jan  4 04:59:04: forwarded to

When I run nslookup on my mac in the default group:

❯ nslookup
Server:		*Router ip*
Address:	*Router ip followed by #number*

Non-authoritative answer:

When I run it from the mac in the ads group:

Server:		*Router ip*
Address:	*Router ip followed by #number*

Non-authoritative answer:

I take it those two being the same is bad?

It seems your clients are using your router as DNS server (at least your mac client does), i.e. they are sending DNS requests to your router, and your router is then forwarding them upstream to Pi-hole.

Pi-hole is seeing those requests as originating from your router.
Presumably, your router is Pi-hole's only client.

For Pi-hole's client-based filtering to work, your clients have to use Pi-hole as DNS server so that they are sending DNS requests directly to Pi-hole.

Would forcing the DNS server of one of my clients to be the pi-hole potentially fix this?

I was just doing some googling around to try and better understand my issue.

This reddit post (and many other posts online that I've seen) all seem to imply that the eero DHCP shouldn't cause any issues with the pi-hole.

I found this blog post (from another reddit discussion at that sets up a pi-hole with eero.

Something interesting is towards the end he notes running

scutil --dns | grep 'nameserver\[[0-9]*\]'

Should only show the pi-hole ip address. When I run it on my mac (note this is a mac in the default group not the ads group) I get:

  nameserver[0] : *eero ip*
  nameserver[1] : *pihole ip*
  nameserver[0] : *eero ip*
  nameserver[1] : *pihole ip*

Just wanted to add a note that my ultimate solution to this was to hardcode the DNS server of devices that needed to go into groups. The eero does override and make the requests come from its IP unless you hardcode the devices DNS to point directly to the Pi-hole.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.