iPhone IOS 15.0.2 with private relay enabled shows isn't compatible with iCloud Private Relay, and should be.
Setting the iphone to use 220.127.116.11 on the same WiFi network allows icloud private relay to work. Disabling pi-hole or allow-listing an individual client doesn't allow it to work either.
This is a fresh Docker install.
There are no blocked entries for mask.icloud.com or mask-h2.icloud.com (which as I understand it are the key records to allow for it to work)
Add special handling of iCloud Private Relay domains
Implement special handling of Apple iCloud Private Relay domains to prevent Apple devices from bypassing Pi-hole.
Originally published at:
As always, please read through the changelog before updating with pihole -up. A new tag for docker image will arrive shortly.
Changes in the embedded dnsmasq-v2.87rc1:
Fix crash if combining server=/domain/# is combined with address=/domain/18.104.22.168(issue reported by Pi-hole)
Add all defined RR types to the table of type names used for query logging (Pi-hole provided patc…
You can turn it off by setting
/etc/pihole/pihole-FTL.conf followed by a
But I want to allow network users to use Private Relay if they want, I don't care about globally disabling it.
There's something not working correctly at the moment - or have I misunderstood the changes in 5.10.1 (I am on 5.10.2) which means that pi-hole will always NXDOMAIN the Apple domains irrespective of what the query log says?
OK, great that works.
Yes, I fully accept I need to read the instructions but having DNS behaviour overridden in a non obvious way is a bit frustrating.
Thanks for the help!
Yes. As long as you don't disable the option in the config file it will always reply with NXDOMAIN. Does the query log says something different for you?
The query log was always showing as permitted, yes, hence it was not obvious to work out what was going on. I assumed the query log was the "truth" but I guess FTL has its own behaviour downstream.
And the Reply? Should have been
I'm pretty sure it was A/AAAA OK/Cached. but I've had to blow the Docker image away and start again now, so sorry, can't easily check.
I'm 99% sure I also checked on other clients using the pi-hole for valid nslookup entries for the Apple domains as well when I was troubleshooting.
What would be a more obvious but still not obtrusive way? We block the Mozilla canary domain the same way. Mozilla even asks developers of projects to do this to preserve local DNS functionality. It is handled by a similar config flag.
It's totally legit functionality - I guess if it were a web UI tick box instead of text config maybe?
Or that the query log said "Blocked by FTL config" ?
I vote for a new query status as well. However, I'm not so sure about showing a working canary domain block in red. But I can see that opinions may differ on this aspect.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.