When I turn on the new iCloud Private Relay ADs are no longer blocked. I presume there is no way to use Private Relay and Pi-Hole at the same time??
No. Private relay sends DNS traffic to an alternate server.
See:
https://discourse.pi-hole.net/search?q=Private%20Relay
Ok - thanks
I just have been reading this and this article.
It looks like you can inform the apple device NOT to use the private relay by creating 2 specific DNS entries for the domains
mask.icloud.com
mask-h2.icloud.com
I currently don't have a MAC available to test this, but if somebody is willing to test this...
create a file /etc/dnsmasq.d/xx-NXDOMAIN.conf, (replace xx with an unused number), content:
server=/mask.icloud.com/
server=/mask-h2.icloud.com/
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.
2 Likes
Thanks for sharing. I'll update my Ipad this moment and let you know if it works
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 think it is worth discussing a by-default implementation of this @Developers
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
It did not trigger the consent warning, but rather the technical issue (yes, I removed it from blacklist before).
[2021-09-21 13:39:38.705 22145M] ICLOUD_PRIVATE_RELAY: Enabled
Sep 21 13:41:15 dnsmasq[22147]: query[A] mask.icloud.com from 10.0.1.64
Sep 21 13:41:15 dnsmasq[22147]: Apple iCloud Private Relay domain mask.icloud.com is Apple iCloud Private Relay domain
Sep 21 13:41:15 dnsmasq[22147]: query[type=65] mask.icloud.com from 10.0.1.64
Sep 21 13:41:15 dnsmasq[22147]: Apple iCloud Private Relay domain mask.icloud.com is Apple iCloud Private Relay domain
Sep 21 13:45:07 dnsmasq[22147]: query[type=65] mask.icloud.com from 10.0.1.64
Sep 21 13:45:07 dnsmasq[22147]: special domain mask.icloud.com is special domain
Sep 21 13:45:07 dnsmasq[22147]: query[A] mask.icloud.com from 10.0.1.64
Sep 21 13:45:07 dnsmasq[22147]: special domain mask.icloud.com is special domain
What ifference triggers the different logging "special domain mask.icloud.com is special domain" and "Apple iCloud Private Relay domain mask.icloud.com is Apple iCloud Private Relay domain"
19 posts were merged into an existing topic: Continuing discussion from iCloud Private Relay
8 votes have been moved.
I rebooted the iPad and it's working now as intended. Maybe this one is on Apple, Private Relay is still a beta feature.
1 Like
Interesting, what does a manual dig mask.icloud.com show? It should be along the lines of
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
Logging for NXDOMAIN is known to be currently looking odd, this will be fixed by
It always was, this is what made me suspect it was the iPad not working correctely.
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.
Well, yes. If the VPN is run on a different server than the Pi-hole, this wouldn't work so I'm a bit worried to may create too high expectations. I'm thinking about if this is a good option or not.
We could make the option accept
-
ICLOUD_PR=block(default) ICLOUD_PR=allow-
ICLOUD_PR=eth0,wlan0(comma-separated interface name list)
Performance-wise this wouldn't have much of an impact because we could iterate the interface list only if the query is one of the two domains above.
Also: You'd likely want to enable it on eth0. Does disabling it over wg0 make any difference? If so, this also rather looks like an Apple bug IMO.
I'd like some feedback from the others involved in here about this.
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[394]: query[type=65] mask-api.icloud.com from 10.0.1.64
Sep 21 21:24:11 dnsmasq[394]: query[A] mask-api.icloud.com from 10.0.1.64
Sep 21 21:24:11 dnsmasq[394]: query[type=65] mask-api.fe.apple-dns.net from 10.0.1.64
Sep 21 22:45:27 dnsmasq[394]: query[type=65] mask-api.icloud.com from 10.0.1.64
Sep 21 22:45:27 dnsmasq[394]: query[A] mask-api.icloud.com from 10.0.1.64
Sep 21 22:45:27 dnsmasq[394]: query[type=65] mask-api.fe.apple-dns.net from 10.0.1.64
Sep 21 23:04:31 dnsmasq[394]: query[type=65] mask-api.fe.apple-dns.net from 10.0.1.64
Sep 21 23:04:31 dnsmasq[394]: 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.