Ads not blocked when using iCloud Private Relay with BLOCK_ICLOUD_PR=false

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Using pi-hole in a docker container from this repository, Pi-hole v5.8.1, FTL v5.13, Web Interface v5.10.1 on a raspberry pi. /etc/pihole/pihole-FTL.conf contains

PRIVACYLEVEL=0
BLOCK_ICLOUD_PR=false
REPLY_ADDR4=10.0.0.2

But when I have iCloud private relay enabled, ads are not blocked. nslookup of the relevant domains shows

○ nslookup mask-h2.icloud.com
Server:		10.0.0.1
Address:	10.0.0.1#53

** server can't find mask-h2.icloud.com: NXDOMAIN

○ nslookup mask.icloud.com
Server:		10.0.0.1
Address:	10.0.0.1#53

** server can't find mask.icloud.com: NXDOMAIN

Expected Behaviour:

Ads should be blocked when using iCloud Private Relay, nslookup should return some sort of non-authoritative answer.

Actual Behaviour:

Ads are not blocked, nslookup returns an NXDOMAIN response.

Debug Token:

Debug token: https://tricorder.pi-hole.net/IeBsG9Mx/

iCloud Private Relay uses it's own DNS servers. That setting disables Pi-hole completely.

In addition, and quite probably not related to your observation (as Dan's remark would already fully explain that), https://github.com/juampe/docker-pi-hole-dot is not Pi-hole's official image, so all bets are off when it comes to judging specific behaviour.

Ah, ok - so the move is to disable iCloud PR on the network one wants to use pi-hole. Got it. Thanks for the fast response!

Yes, though it may be a good idea for us to have the flag (and the Firefox DoH flag) to be settable per group instead of for the whole Pi-hole instance.

Gotcha. I am using this image because it brings DoT along for the ride. If there was a straightforward way to achieve that with the official images, I'd be willing to switch over!

DoT as a client to tunnel to a remote upstream, or DoT as a server for other clients to tunnel to?

My understanding is that is the former using Unbound, which forwards the request to cloudflare

If that is the case then you could do it a lot lighter and you wouldn't need unbound since that is meant more for recursion/authoritative. I'm playing with a few ideas that could address this.

I'd love to hear how to do that better/lighter and would be happy to provide feedback on solutions that are still being developed!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.