Hello,
Since the release of iOS 26.0, we are seeing DNS traffic being blocked from within our NEPacketTunnelExtension on some devices. We have not isolated exact reproduction steps, but DNS resolves successfully for a period of time after enabling "iCloud Private Relay" (varying from 1-day to 2-weeks), until it then fails as MDNSResponder then returns:
mDNSResponder [Q37046] DetermineUnicastQuerySuppression: Query suppressed for <mask.hash: 'REDACTED'> Addr (blocked by policy)
DNS resolution continues to fail for all domains with the above until the device is rebooted.
The Packet Tunnel intentionally does not have a DNS server set and this occurs for traffic from the Extension yet off-tunnel, which needs resolution from the system DNS server (and this configuration works perfectly for a period of time before being "blocked by policy").
The following do not resolve the issue once DNS queries are being "blocked by policy" on affected devices: disconnecting then reconnecting the vpn; toggling airplane mode for 10+ seconds; switching connection between WiFi & cellular data; disabling iCloud Private Relay.
We have currently only seen this on unmanaged devices running iOS 26.0 or 26.1 beta and with iCloud Private Relay enabled. We did not see this issue on iOS 16,17 nor 18. We also have not yet seen this when iCloud Private Relay is disabled nor on iOS 26.0.1, however we cannot confirm whether they too are also affected.
Is there a known a bug with iOS 26.0 & 26.1 Beta 1 that could cause this? How can we prevent DNS requests from NEPacketTunnelExtension being sporadically "blocked by policy" until the device is rebooted?
Many thanks in advance.
until the device is rebooted.
I recommend that you file a bug about this. Things that need a restart to clear are almost always a bug in one layer on the system or another.
Please post your bug number, just for the record.
For your bug to get traction it’ll need to have a sysdiagnose log attached, one that was taken on the affected device after you see the problem. I realise that this might be hard to get due to the intermittent nature of the bug. I have some hints and tips about this in Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem.
Ideally this sysdiagnose log would be:
- Taken on a device with both the Network Diagnostics and VPN (Network Extension) debug profile installed; see our Bug Reporting > Profiles and Logs page for more on that.
- Taken immediately after seeing the problem.
That’s hard if you’re investigating this based on reporting coming in from the field, but keep that in mind if you’re making a concerted effort to reproduce this in a test environment.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"