Thank you for taking a look! And your packet tunnel provider is doing that because? Because we want to provide our users functionality of using our DNS servers without running full VPN, and UX to enable NEDNSSettingsManager is very unintuitive and hard to explain to non-technical users. Adding VPN profile is far easier to explain to our users. I understand we are using NEPacketTunnelProvided not as intended, but we follow the documentation of NEDNSSettings and since Connectivity Assist was introduced in iOS27 Beta the documentation does not longer hold true.

We observe the same problem with NEPacketTunnelProvider. In our case we use it to block specific DNS from being resolved. I tested different DNS servers, they respond in a different manner for a blocked domain, e.g. NXDOMAIN REFUSED 0.0.0.0 127.0.0.1 I noticed in cases (1-3), the system falls back to resolving the domain using cellular network (when Connectivity Assist is enabled). In case 4 it doesn't, but it's not something we want to do on the server side. I reported Feedback to using Feedback Asistant: FB24536764. For me the current behavior, breaks the promise that the documentation makes: https://developer.apple.com/documentation/networkextension/nednssettings/matchdomains?language=objc If matchDomains contains the empty string it becomes the default domain. This is how a split-tunnel configuration can direct all DNS queries first to the VPN DNS servers before the primary DNS servers. And https://developer.apple.com/documentation/networkextension/nednssettings/allowfailover I know for a fact that the system falls back to using Cellular connectivity, because I collected system logs and I see this clearly: 1 - original request correctly returns NoSuchRecord: 2026-08-27 08:12:50.898425+0200 0xf8d8 Default 0x0 924 0 com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1.1.1 Hostname#967e768c:443 failed resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good)] event: resolver:receive_dns @0.017s, error DNS Error: NoSuchRecord 2 - fallback DNS request starts 2026-08-27 08:12:50.898436+0200 0xf8d8 Default 0x0 924 0 com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1 Hostname#967e768c:443 in_progress fallback (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, fallback: {interface: pdp_ip0, agent: 108BFE0A-39C9-4F76-87A7-56A66107F5B3, opportunistic, generation: 589}, LQM: good)] event: fallback:start_fallback @0.017s 3 - fallback DNS requests returns correct domain: 2026-08-27 08:12:50.962099+0200 0xf8af Default 0x0 924 0 com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1.2.1 Hostname#967e768c:443 in_progress resolver (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, dns, uses cell, LQM: minimal)] event: resolver:receive_dns @0.081s 4 - fallback DNS requests finishes 2026-08-27 08:12:51.165473+0200 0xf8af Default 0x0 924 0 com.apple.WebKit.Networking: (Network) [com.apple.network:connection] [C265.1 Hostname#967e768c:443 ready fallback (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, fallback: {interface: pdp_ip0, agent: 108BFE0A-39C9-4F76-87A7-56A66107F5B3, opportunistic, generation: 589}, LQM: good)] event: fallback:finish_fallback @0.284s Also, I collected tcpdump from my iPhone and I see DNS request coming from my cellular IP address to a different DNS server from the one I have set. So yeah, looks like Connectivity Assist could use some improvement before the final release.