and restart pihole-FTL (sudo service pihole-FTL restart)
This will ensure the reply to dig mask.icloud.com is NXDOMAIN. According to the earlier mentioned docs, this dig is used to find geografically localized relay addresses, if there are no addresses in the reply, the apple device will not use any relays (feature disabled).
Again, I haven't been able to test this, so any feedback would be usefull.
If I understand everything correctly, this implies you don't have to make any changes on the apple device.
reply = NXdomain disables apple relay.
reply = IP addresses enables apple relay
so when at home (or protected company network) apple relay would be disabled, as soon you're in the field (no pihole / nxdomain reply), apple relay would be enabled.
Please keep DL6ER in the loop of any results. The firefox canary domain is no longer handeled by dnsmasq settings, the domain use-application-dns.net is handeled with specific FTL code, these new domains may require the same response...
Again, cannot test, no MAC available, so all help is much appreciated...
It works, but not in the automatic way the mozilla cannary domain works.
After getting an iCloud+ subscription (which is needed to enable the private relay feature), I saw requests to mask.icloud.com when using safari. After that was sucessfully resolved, no more requests showed up in Pi-hole. (And, by using QUIC via port 443 my firewall on port 53 was also not stopping this traffic).
I set up the two domains as you proposed above as dnsmasq configs and got a warning.
(Text is in German, it basically says that my wifi is not compatible with private relay. In order to establish internet connection again, private relay must be disabled for that network. But then the network will be able to track my internet activity and my IP could be tracked by trackers and web pages)
After disabling private relay for this network the settings shows that it is disabled for that particular network only
I don't know if you remember this one? TL;DR if use-application-dns.net is on a blocklist, the dnsmasq directive server= doesn't work anymore (mozilla requires the reply to be NXDOMAIN, nothing else). The solution is to have the server= setting and whitelist the domain. This has now been solved by having FTL provide the correct (NXDOMAIN) reply for the domain, regardles of adlist entries.
NOT sure the same aplies here, could you possibly test it? I've already added a server = and whitelist entry for both domains.
Again, cannot test, until my regular mac visitor drops by...
I added it to my blacklist and changed the blocking mode. NODATA also triggers the warning. NULL triggers a different behavior: there will be general OS warning, that private reply is currently not available due to a technical issue but will be reactivated as soon it is available again. It will not deactivate PR for a particular network all together.
I'm not sure which reply I prefer: NXDOMAIN or NULL. While the fist needs a user's consent to disable private relay permanently for a given wifi the second is a more "automatic" solution but inexperienced users might think there is something wrong with their network.
The Apple page writes (second link from jpgpi250 above):
The fastest and most reliable way to alert users is to return a negative answer from your network’s DNS resolver, preventing DNS resolution for the following hostnames used by Private Relay traffic. Avoid causing DNS resolution timeouts or silently dropping IP packets sent to the Private Relay server, as this can lead to delays on client devices.
"Negative answer" can be either NODATA or NXDOMAIN. NULL is not a negative answer.
Hence, I'd say the solution should be NXDOMAIN because the behavior seen when NULL blocking is in place is not documented and may silently be "updated away" in the future.
Yes. FTL has a special facility that is designed to handle special domains. So far, we've had only one. Now there is another (even when this time, there seems to be two).
Which is necessary in this case. Firefox deploys its DoH silently if not stopped by the canary domain. Here, users explicitly enable a feature (they even have to register) so it is only fair that their phone tells them that the service cannot be used in the current network.
edit Please test
pihole checkout ftl new/iCloud_private_relay
BLOCK_ICLOUD_PR can be used to switch this off. The option defaults to true
Is it possible for FTL to treat queries from different network interfaces differently with the private relay option (e.g. enable this new option for eth0 and disable it for wg0)?
VPN traffic automatically bypasses iCloud Private Relay, so if someone uses a split-tunnel VPN only for DNS, they can use Pi-hole and the relay at the same time. Additionally, if a full-tunnel is used, Private Relay is bypassed anyway. However, this is still useful when on local networks.
I just tested it using a Wi-Fi network using a DNS server that does not block the canary domains, while my phone was connected to a VPN with a Pi-hole that does block the canary domains (I made a config file as described in the comment: iCloud Private Relay - #4 by jpgpi250 and did not use the PR). I got the message saying that the network was not compatible with Private Relay, and Safari gave errors when trying to load any webpage that Safari couldn’t connect to iCloud Private Relay.
Maybe this is an oversight by Apple, but it seems like the DNS server from the VPN is used to determine whether the relay is to be enabled or not.
I can confirm this. I set-up a split DNS wireguard on my iPad and blocked the requests by Pi-hole and iPadOS thinks the wifi is not compatible with Private Relay. I think they do not know which traffic goes via the VPN so they assume it must be the wifi connection that prevents PR from being established.
Interestingly a few requests bypassed the tunnel and were send via the wifi interface (10.0.1.64):
Sep 21 21:24:11 dnsmasq: query[type=65] mask-api.icloud.com from 10.0.1.64
Sep 21 21:24:11 dnsmasq: query[A] mask-api.icloud.com from 10.0.1.64
Sep 21 21:24:11 dnsmasq: query[type=65] mask-api.fe.apple-dns.net from 10.0.1.64
Sep 21 22:45:27 dnsmasq: query[type=65] mask-api.icloud.com from 10.0.1.64
Sep 21 22:45:27 dnsmasq: query[A] mask-api.icloud.com from 10.0.1.64
Sep 21 22:45:27 dnsmasq: query[type=65] mask-api.fe.apple-dns.net from 10.0.1.64
Sep 21 23:04:31 dnsmasq: query[type=65] mask-api.fe.apple-dns.net from 10.0.1.64
Sep 21 23:04:31 dnsmasq: query[A] mask-api.fe.apple-dns.net from 10.0.1.64
Greetings, new here, but I've been running Homebridge and Pihole for about a year on a Raspberry Pi with my Amplifi Alien router and my iMac, Mac mini, and several iPhones and iPads, and I haven't had any issue(s) that I can say/tell with iCloud Private Relay.