iCloud Private Relay: network blocking set up exactly as documented (NXDOMAIN for mask.icloud.com / mask-h2.icloud.com), but iOS shows no alert

We run a Wi-Fi network with our own captive portal and want iOS clients to be told that Private Relay is not available here, as described in Prepare your network or web server for iCloud Private Relay and WWDC21 session 10096.

Our setup:

Resolver: Unbound, handed out via DHCP, with local-zone: "mask.icloud.com" always_nxdomain and local-zone: "mask-h2.icloud.com" always_nxdomain. The network is IPv4-only. The captive portal intercepts all UDP port 53 traffic and drops everything else (e.g. port 853). TCP port 53 is not served. We also tried NXDOMAIN for mask-api.icloud.com, apple-native-relay.apple.com, mask.apple-dns.net, mask-api.fe.apple-dns.net and mask-t.apple-dns.net, with no change. [Result of our resolver log: do queries for the mask hosts arrive from the test iPhone, and what do we answer? Before and after captive-portal login?]

What the documentation promises: “users will be alerted that they need to either disable Private Relay for that network, or choose another network.”

What happens: On [iPhone model], iOS [exact version/build], with Private Relay enabled in iCloud settings and “Limit IP Address Tracking” [on/off] for this Wi-Fi, joining our network shows no message at all. [What the user sees instead: Safari loads normally / pages fail / nothing changes.]

Counter-observation: On a hotel guest network (Marriott) the same kind of device did show a notice, so the feature seems to still work on current iOS. We do not know how that network blocks Private Relay.

Related reports: thread 687684 and thread 722315 describe a similar gap (network-level NXDOMAIN gives no alert, on-device DNS filtering does). Our own report: FB[number], no response so far.

Questions:

Which conditions must be met for iOS to show the message? Is NXDOMAIN for the two documented names enough, or does the alert also depend on other hostnames, the DNS response type (NXDOMAIN vs. NODATA), or the state of the network (e.g. before/after captive login)? Is the alert suppressed when “Limit IP Address Tracking” was turned off for that Wi-Fi earlier, or when Private Relay has already connected successfully on another network? Is the documentation still accurate for current iOS releases? If not, could it be updated?

Our own report: FB[number], no response so far.

What was that bug number?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sorry, i somehow forgot to Full the placeholders.

The missing ID is FB24890961 (Network-level blocking of mask.icloud.com/mask-h2.icloud.com no longer triggers the documented Private Relay alert – missing third domain or DNS-bypass issue?)

Thanks for that.

I’m not sure what’s going on here, but I do nevertheless have a suggestion. You can help your bug get traction by adding a sysdiagnose log to it. Specifically:

  1. On a test device, install the Network Diagnostics and VPN (Network Extension) debug profiles. See our Bug Reporting > Profiles and Logs page.
  2. Reproduce the issue, noting down the time.
  3. Immediately trigger a sysdiagnose log.
  4. Add that to your bug report, along with the timestamp from step 2.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"