My latest outcome from troubleshooting this issue:
tested the last 12 hours and can confirm that BLOCK_ICLOUD_PR=false in pihole-FTL.conf is a valid workaround for now. Safari and Mail on iOS 15.5 and macOS 12.4 are now working as expected, all my affected websites are loading correctly.
My iOS/macOS settings are (which is Apples default setting):
Private Relay = OFF
Limit IP Address Tracking in WiFi settings = ON
Adblocking via PiHole is also working as expected on these Apple devices, I can see the blocked URLs in the PiHole log correctly.
Looks for me that the newest releases of iOS and macOS are pissed if anyone is blocking Apples DNS servers and they cannot be reached.
FYI: I have tested the following FTL settings:
NO BLOCK_ICLOUD_PR config in pihole-FTL.conf (PiHole default)
SET BLOCK_ICLOUD_PR config in pihole-FTL.conf to true
SET BLOCK_ICLOUD_PR config in pihole-FTL.conf to false
Only TEST3 with value false is working without issues in combination with Apples default settings on iOS / macOS.
Note that setting BLOCK_ICLOUD_PR to false would then allow any Apple client to by-pass Pi-hole via iCloud Private Relay, including those iOS devices that would otherwise honor the masked DNS replies as specified by Apple and work correctly.
Based on your personal preference and actual device usage in your network, you should individually weigh up whether you want to disable that setting or not.
thanks... yes, I am aware about it.
But it is the only possibility if you have many Apple devices in the network with the latest releases running to keep them "stable". It is impossible for me to configure each device manually.
From the "Adblock-perspective" it works great... but as you said: Users are able to enable Apples Private Relay and can pass PiHole. In my case I let the choice the user if ads should be blocked.
Hi all,
Another grateful user for finding this thread after pulling my hair out for a number of days!
Just wanted to check whether we are still considering this as a work around, and there is belief a more permanent fix that plays well with Apple devices can be implemented.
This is the workaround we can currently offer. We can not do much about that Apple decided to be offended if we block their canary domains (which they suggest we should do). Pi-hole offers a way do disable the blocking, there is nothing we could do on top of this as long as we have no documentation to rely on.
Thanks guys, was puzzled for days why some sites loaded terribly slow. Switched off Wifi which fixed it and then tried bypassing pihole.
Is there an easy explanation of what is going on for noobs like me? What I seem to gather from the above is that the "limit ip adress tracking" in IOS, suddenly (since latest IOS update) causes issues as there is something (canary?) pihole blocks? This option which I just added to my config stops pihole blocking this - but what was being blocked (I assume there is a good reason for blocking this).
I see. I checked my blacklist and I did have 2 other related apple blocks that I added a long time ago but I dont remember why. Unsure if they are relevant but sites did not load until I added the 2 ‘mask.’ domains mentioned above.
The domains that were already in my blacklist for must be almost 2 years now were:
doh.dns.apple.com
And
doh.dns.apple.com.v.aaplimg.com
Sorry I dont remember why I added these but likely for a similar reason in the past.
This is Apple's feature: They specifiy how to deal with it - they own their software, so it' s only fair that they change behaviour at times. But they should then update their docs accordingly.
Honestly, this should be raised with Apple.
They are the ones in the position to properly address that, either by updating their OS or their docs.
NXDOMAIN and NOERROR null blocking isn't the same. That's what the user "pallebone" did other than Pi-Holes default for Apples Private Relay. It blocks with NXDOMAIN while normal blacklistign answers with 0.0.0.0.