CleanBrowsing Family filter bypass on Apple devices with Safari inPrivate browsing

[Blezzz]

Hi, I have noticed some strange behavior when using the Family filter CleanBrowsing‑1 applied at the WAN level or through DNS Director.

When using the Safari browser in Private mode, the DNS filter can be bypassed and adult sites are not blocked.

If I change the DNS filter to CleanBrowsing‑2, AdGuard, or ControlD, then the Private tab cannot bypass the filter. This issue only occurs when CleanBrowsing‑1 is selected.

I get the same results if I apply the DNS filter at the LAN level through DNS Director.

DNSLeakTest shows that the Private tab in Safari bypasses the filter by using Apples Relay (Apples Private Relay is disabled in settings), which is expected. However, it is strange that this bypass does not occur when any of the other filters are selected. In those cases, DNSLeakTest shows that the family DNS filters are working correctly.

I tried with FW 3004.388.10 and 3004.388.11

Also, I am locked into using Safebrowsing-1 as this is the only family filter that allows comments on YouTube.

 

[Twiglets]

According to google et al:

Interaction with Private Browsing

Bypassing DNS Filters: When using Private Browsing, Safari may bypass DNS filtering services like Pi-hole etc, which can lead to unexpected behavior, such as ads appearing or certain content being accessible that would otherwise be blocked.

iCloud Private Relay: If enabled, this feature routes Safari traffic through Apple’s servers, further obscuring DNS requests from local filtering services.

By default Private Browsing does NOT use DoH for privacy (unlike Firefox for example), it uses icloud Private Relay, as you have found.
Additionaly Private Browsing may change your dns requests on the fly to maintain 'privacy' according to Apples 'rules'.

To get the DNS filtering to work you need to NOT use Private Browsing as far as I can see.

 

[RMerlin]

Cleanbrowsing-2 blackholes Apple's canary domain, which is why the description says it also prevents VPN/proxy usages (Apple Relay is really a VPN):

$ dig @185.228.168.168 mask.icloud.com

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @185.228.168.168 mask.icloud.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16088
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mask.icloud.com.        IN    A

;; AUTHORITY SECTION:
mask.icloud.com.    3600    IN    SOA    cleanbrowsing.rpz.noc.org. accesspolicy.rpz.noc.org. 1 7200 900 1209600 86400

;; Query time: 11 msec
;; SERVER: 185.228.168.168#53(185.228.168.168) (UDP)
;; WHEN: Mon Jan 05 16:29:19 EST 2026
;; MSG SIZE  rcvd: 118

Cleanbrowsing-1 does not:

$ dig @185.228.168.10 mask.icloud.com

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @185.228.168.10 mask.icloud.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14375
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mask.icloud.com.        IN    A

;; ANSWER SECTION:
mask.icloud.com.    8983    IN    CNAME    mask.apple-dns.net.
mask.apple-dns.net.    158    IN    A    172.224.186.203
mask.apple-dns.net.    158    IN    A    172.224.186.17
mask.apple-dns.net.    158    IN    A    172.224.186.14
mask.apple-dns.net.    158    IN    A    172.224.186.20
mask.apple-dns.net.    158    IN    A    172.224.186.200
mask.apple-dns.net.    158    IN    A    172.224.186.196
mask.apple-dns.net.    158    IN    A    172.224.186.12
mask.apple-dns.net.    158    IN    A    172.224.186.197

;; Query time: 8 msec
;; SERVER: 185.228.168.10#53(185.228.168.10) (UDP)
;; WHEN: Mon Jan 05 16:30:54 EST 2026
;; MSG SIZE  rcvd: 204

 

[RMerlin]

The only way you can prevent the use of Icloud Private Relay is to use a DNS server that will backhole the canary domain. If you use DNSDirector, that means using Cleanbrowsing-2. If you use anything else, it has to be on the WAN page, but additionnaly you must also enable "Prevent client auto DoH" on the WAN page. That way:

1) Client device talks to router, which will backhole the domain, disabling Private Relay
2) Other queries are sent to the DNS server you configured on the WAN page

If you want to use DNSDirector to also prevents bypassing that setup, then DNSDirector must be set to point at "Router", which allow it to first handle canary queries, and send everything else configured on the WAN page.

Just using DNSDirector won't work unless the remote server also blackholes the canary domain, like Cleanbrowsing-2 does.