What is the Best Practice to block iCloud relay?

[phampx]

What is the best practice method to block iCloud relay without impacting iOS users too much? Apple says to NXDOMAIN the following below. 

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

Prepare your network or web server for iCloud Private Relay - iCloud - Apple Developer

For the PA though,... should we... create a policy to block, deny or use a URL custom block object rule?

These are some other domains/FQDN I have found:

• configuration.Is.apple.com
• gateway.icloud.com
• gsp85-ssl.Is.apple.com
• iphone-Id.apple.com
• mask-api.icloud.com
• mask-t.apple-dns.net
• mask.icloud.com
• mask-h2.icloud.com

[JayGolf]

Hi @phampx ,

I would recommend leveraging dns sinkholing at the Palo instead of nxdomain at the DNS level. You can accomplish this via an EDL (Domain List) tied to an AS profile that is referenced in a security policy. DNS sinkholing via the Palo achieves the same effect, but with visibility and logging, which you don't get at the DNS level. Also, DNS sinkholing over URL Filtering/ FQDN-based blocking is efficient in that the fw stops the request at DNS lookup so it doesn’t need to build a full session compared to URL Filtering/fqdn object.

1. You can easily create an EDL using a simple .txt file hosted in a location accessible to the firewall (internal web server/S3 or Cloud storage/GitHub raw link,etc) and enter the private relay domains you have. 
2. Add the EDL (Type: Domain List) under Objects -> External Dynamic Lists and set it to refresh as you desire (hourly is the fastest).
3. Reference it in an Anti-Spyware profile -> DNS Policies tab, and set Action = Sinkhole.
4. Attach that profile to the security rule handling outbound DNS traffic, preferably before your general internet security policy or any policy that has url filtering attached. ** iCloud Private Relay domains are typically categorized by PAN-DB under "Proxy Avoidance and Anonymizers" and might be blocked if you have that enabled.

**Side Note (if you choose to block via Security Policy instead of Sinkhole)...

Blocking via FQDN objects in a security policy would be simpler and have the same effect as URL Filtering in this case since you're not needing wildcards and only targeting domains like "mask.icloud.com" and "mask-h2.icloud.com", rather than something like mask.icloud.com/private-relay/api/init. Full URL path-based blocking would require url filtering w/ SSL decryption to inspect the HTTP path inside the TLS session. 

[BPry]

@phampx,

If this is for managed devices you can simply set allowCloudPrivateRelay and it will ensure that it is disabled on the device itself which is the most effective way to manage things. 

If you block mask.icloud.com or mask-h2.icloud.com on devices that you don't manage, this will cause noticeable impact to your Apple endpoints. There's no way around this block triggering a delay for these endpoints; Apple has made changes so that blocking these requests doesn't cause as big of an impact as it did initially when this feature launched, but people will still notice 'slowness' since it will always attempt to utilize Private Relay first and then need to fallback to normal communication.