Safari won't finish loading certain sites after iOS 15.5 / MacOS 12.4 upgrade

General
25

Is this setting visible in the Pi Hole GUI?

26

Nice. Hopefully we can get BLOCK_ICLOUD_PR added as an environment variable option for those launching pihole with docker scripts/config files.

27

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,

/etc/pihole/pihole-FTL.conf

2 Likes
28

The specific file is:

/etc/pihole/pihole-FTL.conf

2 Likes
29

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.

30

Hi @Bucking_Horn

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.

31

You already can use any of pihole-FTL's configuration options with a Docker Pi-hole by defining the respective FTLCONF_[SETTING] advanced variable.

32

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.

Thank you
Christian

33

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.

34

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?

35

Thank you for the feedback. I was just asking to have a better grasp of the situation.

Much appreciated.

36

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).

37

I resolved the issue by adding the domains apple suggested to my blocklist in pihole:

mask.icloud.com
mask-h2.icloud.com

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.

38

Interesting, because this is exactly what Pi-hole does by default (i.e. by its default BLOCK_ICLOUD_PR=true).

39

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.

41

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.

42

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 NXDOMAIN to A and AAAA queries of mask.icloud.com and 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.

1 Like
43

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?

44

Could be a misunderstanding then:
Your answer is referring yubiuser's post.

45

Yes, because his statement was "plain wrong", to say it in your words...