Pi-hole working, but low blocking percentage

[turop]

Expected Behaviour:

I have been using pi-hole for a while, and its been great. I have it running on a Rasberry pi 3b. I use the standard blocklist and also added those from the Firebog. The Pi is running on raspberry pi OS. I update regularly, both the pi and pihole, I am on V5.18.3, FTL V5.25.2 and Web interface v5.21.

I have synology kit around the house mainly, specifically I use a Vigor 130 ADSL/VDSL modem, before a Synology RT2600ac router (I then have an additional 2600 and 2200 units running a mesh wifi network). My network, and Pi are connected via ethernet.

In my router software, I have the pi's IP as my preferred DNS server and alternative DNS server. I have in the past also enabled a further setting on the router to 'Enable DoH (DNS over HTTPS)' which I had enabled and set to cloudflare. I run DHCP on my router rather than the pi-hole.

On the Pi itself, I have cloudflare (DNSSEC) set as IPv4 with both boxes ticked. IPv6 is unchecked. I have Allow only local requests ticked, along with all three DNS advanced DNS settings checked.

I generally access the pi via the web-browser (firefox and Edge), and update over SSH.

I have multiple PCs, PS5, phones tablets all using the network.

Actual Behaviour:

When looking at the main pi-hole dash, I have 387,843 queries, but only 0.4% blocked. This number was lower but has climbed a little since I unchecked the DNS over HTTPS setting on my router.

Although I generally don't see many ads, I wonder if I have something incorrectly set somewhere.

Looking at the Top permitted Domains, I can see 351164 for api.onedrive.com, and 11864 checkip.synology.com, and with those numbers I can see how my percentage blocking is low.

I also had the rate warning previously, but cleared yesterday and it has not returned yet.

Debug Token:

KVQCoL2m

[Bucking_Horn]

@turop

Looking at the Top permitted Domains, I can see 351164 for api.onedrive.com

Those would be more than 240 requests per minute.

The DNS record for that domain comes with a TTL of 4 minutes, so a well-behaving client could be expected to request that once every 4 minutes, or 360 times in 24 hours.

Pi-hole just makes those requests visible - it is your clients that are producing them.

You should try to identify the client that is issuing those requests and find a way to control that client's behaviour.

[turop]

@Bucking_Horn

Those would be more than 240 requests per minute.

The DNS record for that domain comes with a TTL of 4 minutes, so a well-behaving client could be expected to request that once every 4 minutes, or 360 times in 24 hours.

Pi-hole just makes those requests visible - it is your clients that are producing them.

You should try to identify the client that is issuing those requests and find a way to control that client's behaviour.

Thank you for the reply, it is much appreciated.

What would be the best way to identify the client? When clicking on api.onedrive.com on the 'Top Permitted Domains', I get the processing screen, and then a "An unkown error occured while loading the data". Is that the correct way?

[Bucking_Horn]

(Side note: There's no need to quote whole posts. )

Usually, yes, but the number of queries may exhaust the webserver's memory in your case.

Try retrieving that directly from Pi-hole's database instead:

pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db "SELECT count(*), client FROM queries WHERE domain = 'api.onedrive.com' AND timestamp > strftime('%s','now','-1 day') GROUP BY 2 ORDER BY 1 DESC;"

[turop]

@Bucking_Horn

(Side note: There's no need to quote whole posts. )

Noted, thanks!

@Bucking_Horn

Try retrieving that directly from Pi-hole's database instead:

I was expecting a list, but all I get is the IP of the router, and a current count of 382273. I assume this is just telling me the volume is all coming via the router, but the detail i.e. the client info, is not stored on the pi, but the router, is that correct?

I wonder if its coming from my NAS, I can't prove this, but there is a cloudsync function which links to onedrive. I could pause this functionality and see what effect that has on the pi-hole. I have also posted on synology forums about constant polling.

[Bucking_Horn]

@turop

I was expecting a list, but all I get is the IP of the router, and a current count of 382273

Indeed, your debug log shows that your router is distributing itself as local DNS server:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 306 bytes from eth0:10.0.4.1
     Offered IP address: 10.0.4.26
     DHCP options:
      Message type: DHCPOFFER (2)
      dns-server: 10.0.4.1
      router: 10.0.4.1
      --- end of options ---

That would suggest that you have configured your router to use Pi-hole as its upstream DNS server, as opposed to having it distribute your Pi-hole machine's IP as local DNS server.

That is a valid configuration, but as your router aggregates your network's DNS traffic, becoming Pi-hole's only client, you won't be able to attribute DNS requests to individual clients.

If your router supports it, it would be preferred if you'd configure it to tell its clients to use Pi-hole directly.

@turop

I wonder if its coming from my NAS, I can't prove this, but there is a cloudsync function which links to onedrive. I could pause this functionality and see what effect that has on the pi-hole

That 's a good idea.
How did that turn out?

[turop]

@Bucking_Horn

That would suggest that you have configured your router to use Pi-hole as its upstream DNS server, as opposed to having it distribute your Pi-hole machine's IP as local DNS server.

That is a valid configuration, but as your router aggregates your network's DNS traffic, becoming Pi-hole's only client, you won't be able to attribute DNS requests to individual clients.

I have had a poke around in my router settings, it seems there is a further section under each local network under primary DNS under IPv4DHCP server. So I have added pihole IP here too, and to the guest network and my IOT network.

Is this now preferable?

@Bucking_Horn

If your router supports it, it would be preferred if you'd configure it to tell its clients to use Pi-hole directly.

I am not sure on this.

@Bucking_Horn

That 's a good idea.
How did that turn out?

This seems to be the major issue. Two of the three onedrive profiles I back up seem to constantly sync, I don't know why. I can't solve yet, but if I pause them, network traffic drops significantly, with DNS requests dropping from 3.5k per 10 mins to 300 or so. I can mitigate this a bit by only have the onedrive profiles update once a day, when again network dns requests will rocket. I need to work out why these two profiles are different so I can fix it.

[Bucking_Horn]

@turop

@Bucking_Horn

If your router supports it, it would be preferred if you'd configure it to tell its clients to use Pi-hole directly.

I am not sure on this.

Based on above DHCPOFFER, you've succeeded in having your router's DHCP server announce your Pi-hole machine's IPv4 address as local DNS server.

As your router has link-local IPv6 connectivity, you should also verify its IPv6 DNS configuration options (which potentially would be a bunch of options labeled with one or more of NDP/SLAAC/RA and perhaps DHCPv6).
Your debug log shows that at least the Pi-hole host machine currently isn't aware of any IPv6 DNS server addresses (which is absolutely ok, as serving DNS via IPv4 is sufficient).

@turop

I wonder if its coming from my NAS

@turop

This seems to be the major issue. Two of the three onedrive profiles I back up seem to constantly sync

So your NAS is syncing those profiles.

You could check if your NAS runs a DNS stub resolver.

It probably doesn't, and in that case, installing one may prevent those requests from registering with Pi-hole that often:
Your profiles would still request resolution, but via the stub resolver. That resolver must in turn be configured to forward DNS requests to Pi-hole exclusively, and doing so, it should honor the TTL, and serve your profile's requests from cache, rather than forwarding them to Pi-hole, only renewing them if a TTL has expired.

[turop]

@Bucking_Horn

Based on above DHCPOFFER, you've succeeded in having your router's DHCP server announce your Pi-hole machine's IPv4 address as local DNS server.

Thanks - good to know something has worked.

@Bucking_Horn

As your router has link-local IPv6 connectivity, you should also verify its IPv6 DNS configuration options (which potentially would be a bunch of options labeled with one or more of NDP/SLAAC/RA and perhaps DHCPv6).
Your debug log shows that at least the Pi-hole host machine currently isn't aware of any IPv6 DNS server addresses (which is absolutely ok, as serving DNS via IPv4 is sufficient).

I have turned off IPv6 in the main router Internet Connection settings. Alternatively, I could switch on the IPv6 functionality and then and enable it, and then add the primary and secondary dns. But I am not sure this is worth doing.

@Bucking_Horn

You could check if your NAS runs a DNS stub resolver.

It probably doesn't, and in that case, installing one may prevent those requests from registering with Pi-hole that often:
Your profiles would still request resolution, but via the stub resolver. That resolver must in turn be configured to forward DNS requests to Pi-hole exclusively, and doing so, it should honor the TTL, and serve your profile's requests from cache, rather than forwarding them to Pi-hole, only renewing them if a TTL has expired.

I can manually configure the DNS server on the NAS, this is currently set to the default gateway - would that help? And it currently does not act as a DNS stub resolver with out additional software.

[turop]

Things seem improved. I have been able to update my one-drive back up settings on my NAS, which looks to have eased the situation.

I am also seeing different clients (phones etc) now on the Pi, although I am not sure why this is.

Also, I am only running one pihole currently, although I would like duplicate my current pihole, is there a way to do that? Backup and restore maybe? Would it need to be another 3b, or could I use a 4 etc?