Technical Tip: Long Initial Page Load Times Caused by Apple Private Relay and Incomplete DNS Filtering

Description

This article describes how to fix long initial page‑load delay or DNS probe failures on guest Wi‑Fi caused by Apple Private Relay. This behaviour is observed when DNS filter entries for Private Relay mask domains lack explicit block actions.

Scope

FortiGate-Azure, FortiGate-VM.

Solution

DNS domain‑filter entries matching mask.icloud.com have no action set, so the DNS queries are resolved normally.

Apple Private Relay expects an NXDOMAIN response to immediately disable the feature; In the absence of NXDOMAIN, the client retries TCP/QUIC for ~60–120 seconds before timing out. This is causing the observed delay or DNS probe errors.

Disabling QUIC or UTM alone does not force Private Relay off if DNS returns valid addresses; DNS behavior is the decisive signal.

Immediate fix: Check each DNS domain‑filter entry for Private Relay explicitly blocks the domain so the client receives a blocking response:

config dnsfilter domain-filter
 edit 115
  config entries
  edit 1
   set domain "*mask.icloud.com*."
   set type wildcard
   set action block
   next
  edit 2
   set domain "*mask.icloud.com*.<other>"
   set type wildcard
   set action block
   next

...

end
next
end

Alternative mitigations.

• Return NXDOMAIN from your authoritative DNS for Private Relay mask domains.

• Block QUIC (UDP/443) or specific Private Relay endpoints at the firewall for guest VLANs if DNS control is insufficient.

• Enforce device profiles for managed devices to disable Private Relay where policy requires.

• If behavior persists after correct DNS blocking, collect DNS/webfilter logs and packet captures, and consider contacting Apple Support with logs.