My setup is pihole on RaspberryPi (PiHole) - fully up-to-date
Standard set-up but I also use NAT translation rules on my sonicwall to catch all DNS traffic (even DNS traffic trying to use external servers) and push it to the PiHole (exception being the PiHole itself of course).
Everything has worked fine forever but since upgrading my iPad to iPadOS 16.1.1 and my iPhone to 16.1.2 ZERO adds are being blocked on these devices
I'm aware of the BLOCK_ICLOUD_PR=true/false settings and aware of the icloud/private relay/on/off settings. Plus I have also tried to blacklist mask.icloud.com and mask-h2.icloud.com but no combination of these settings now works. Previously these did work in IOS15.
Apple have changed something again and I have no idea what or what to do to block adds again.
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Hi, I had something similar after updating my iPad to iOS 16.1.
I found that the DNS IPv6 addresses on my iPad (Wifi settings) were pointing back at my router NOT to the piHole so bypassing the piHole filters.
Because my router is locked down (BT Smart Hub) I am unable to change the DNS servers. I am therefore using the piHole as the DHCP server supplying IPv4 addresses and DNS servers with no problems. Unfortunately my router is still broadcasting IPv6 DNS addresses, alongside the piHole IPv6 LLA.
It's possible that Safari started using IPv6 DNS after updating.to 16.1. Anyway I've had to manually set the IPv6 DNS address on my iPad to point at the piHole and this stopped the ads appearing.
Not really a full solution, but as I can't stop my current router from issuing IPV6 DNS addresses it will have to suffice until I can replace the router.
Hope this helps
Thanks I fixed it by telling by DHCP to only give out my internal DNS server and the PiHole as DNS. It was using 8.8.8.8 as secondary but that should have worked and does work for everything else, as the sonicwall NAT redirects all outbound DNS queries to the internal DNS. It seems that iOS uses something new to query 8.8.8.8 that does not get picked up by the Sonic. Some sort of tunnelling.
Yeah thanks I get that but I have a NAT loopback rule that pushes all outgoing DNS request to the pihole. This is in place for those devices that secretly use other DNS servers even though they’re on your DHCP scope and meant to be using your internal ones. This has worked fine until now, as all calls to external servers loopback to the pihole. However, with the new iOS implementation it seems to be doing DNS via https even when asked not to. So I’ve now blocked all https traffic to known global DNS providers. This has worked.
This has not been my experience. Multiple IOS devices running IOS 16 latest (including the iPad on which I am typing this), and they all use Pi-hole as expected.
With this setup, what was the purpose for providing 8.8.8.8 in your DHCP DNS assignments?
