I've installed PiHole on an ubuntu 22.04 container on proxmox.
During the installation process, I manually set the static IPv4 address while leaving IPv6 as dynamic.
The issues I'm facing:
Variable performance in different working environment:
I have xfinity and the xFi router so I was unable to change the router DNS for network wide Pihole deployment
After manually reconfigured the IPv4 DNS for each local device, IOS devices (mac & ipad) had a significant higher number of ads (and queries) blocked compared to other devices within the network (windows, linux [pop!os], android phones).
-- nslookup google.com showed these devices were not using the PiHole DNS
-- I then manually reconfigured the IPv6 DNS (which was randomly assigned by the router during the installation process) for the windows and linux laptops. nslookup google.com is now using the PiHole DNS. This increased the amount of ads and queries blocked, which then led to issues #2 ....
Client [...] has been rate-limited for at least 9 seconds (current limit: 1000 queries per 60 seconds)
I've been using only the windows desktop and started to notice the above error for both its IPv4 and IPv6. As mentioned above, I manually reconfigured both the IPv4 and IPv6 DNS's for all non-IOS devices.
Error in NTP client: Failed to adjust time during NTP sync: Insufficient permissions
I received this error immediately after the installation. The proxmox host is displaying the correct time but not the Pihole CT. I added the following line to the pihole.conf file but didn't resolve the issue: lxc.mount.entry = /dev/rtc dev/rtc none bind,optional,create=file
My questions:
Why was there a difference in pihole performance between IOS vs non-IOS devices?
Was manually reconfiguring both IPv4 & 6 DNS' a good solution? Even then, I'm only getting 60% blocked - I know I shouldn't expect 100% blocked but that is on the low side?
What can I do to address the rate limiting?
would issue #3 with the time syncing effect performance? If not then I wouldn't stress about it.
Do you know what specific domains are being blocked? I would presume it is iCloud relays.
"Private Relay can be turned off for a specific network using the Limit IP Address Tracking setting. If you turn off Private Relay for a specific network, the setting for that network applies to all of your devices for which Private Relay is turned on. If you regularly switch between multiple network configurations (such as Dual SIM or Wi-Fi and Ethernet), make sure that this setting is set for each network independently."
If, for some reason, you do not want those devices to use Pi-hole, change BLOCK_ICLOUD_PR. It is easy to rate-limit an iOS device because it will not stop phoning home. In your /etc/pihole/pihole.toml, you need to set BLOCK_ICLOUD_PR=false.
I can't even find out what exactly that domain is. I have a minor concern it is malicious, but otherwise, etaHUB is a wireless charging platform for electric vehicles.
In your current Pihole configuration, are you utilizing its NTP sync? If not, it's nothing to worry about.
I just realized that I set it up as an unprevileged container so it wouldn't have access to timesyncd. That takes care of issue #3 and question #4 then. Thank you!
To address #1, I'm not sure. Pihole should be blocking based on domain queries, so every device would be equal.
Addressing #2, based on your ISP, being child-company of Comcast, who don't appreciate customers tinkering with anything and love spying on all your data and queries, I'm not surprised that you still can't change the DNS from the router.
That being said, I believe manually configuring the DNS for users on the home network is the best decision.
I'm still not sure if my pihole is performing optimally. I'm still experiencing ads on a few sites. It was blocking ~60% queries when I first set it up 2 days ago, now running at 37%. I have ~300k domains on my block list.
I'm not sure what ads specifically will show that you're seeing, but I've found that over time, the actual blocked queries lowers. I'm not sure if it's due to caching specific requests so that it already knows to reject it and therefore it doesn't show in the statistic, but
Whether a query is blocked due to a cached entry, or blocked on first request, it still counts as a blocked query.
You can verify this yourself by repeatedly running an nslookup command for a blocked domain and watching the blocked query counter increase.
Also note that the default TTL for a blocked domain is 2 seconds by default. Not a long time for any significant caching to occur.
# FTL's internal TTL to be handed out for blocked queries in seconds. This settings
# allows users to select a value different from the dnsmasq config option local-ttl.
# This is useful in context of locally used hostnames that are known to stay constant
# over long times (printers, etc.).
# Note that large values may render whitelisting ineffective due to client-side
# caching of blocked queries.
blockTTL = 2
Variation over time is normal. Your clients don't make the same domain requests over and over.
The dashboard shows the most recent 24 hours, and the client behavior changes constantly over this period (and from the day before, and the day before that).
Use these tools to determine the source of the ads:
