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.
Posted this also to: https://www.reddit.com/r/pihole/comments/utab8p/safari_wont_finish_loading_certain_sites_after/
Is this setting visible in the Pi Hole GUI?
Nice. Hopefully we can get BLOCK_ICLOUD_PR added as an environment variable option for those launching pihole with docker scripts/config files.
Is this setting visible in the Pi Hole GUI?
It's not. Go into your root directory of the pihole, and you should see the file pihole-FLT.conf
EDIT: Thanks to jfb,
The specific file is:
Note that setting
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.
You already can use any of
pihole-FTL's configuration options with a Docker Pi-hole by defining the respective
FTLCONF_[SETTING] advanced variable.
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.
The BLOCK_ICLOUD_PR=false workaround is working for me for web, but is there something similar or related that's stopping emails downloading properly?
Thank you for the feedback. I was just asking to have a better grasp of the situation.
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 resolved the issue by adding the domains apple suggested to my blocklist in pihole:
Now all sites I tested so far that didnt load now load fine.
I rebooted my iphone after changing/adding that to clear dns cache.
Interesting, because this is exactly what Pi-hole does by default (i.e. by its default
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:
Sorry I dont remember why I added these but likely for a similar reason in the past.
Well, that is not "exactly" the same I guess. Pi-Hole blocking answer is by default NOERROR with an A-record 0.0.0.0 (null blocking mode).
But the implementation of blocking Apples Private Relay by default answers with NXDOMAIN.
Maybe this is here the crucial difference.
That assumption of yours is plain wrong.
Quoting from our docs for
BLOCK_ICLOUD_PR as linked numerous times in this topic:
BLOCK_ICLOUD_PR=true|false (PR #1171)¶
Should Pi-hole always replies with
AAAA queries of
mask-h2.icloud.com to disable Apple's iCloud Private Relay to prevent Apple devices from bypassing Pi-hole? This is following the recommendation on Prepare Your Network or Web Server for iCloud Private Relay - Support - Apple Developer
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.
This is a difference don't you think?