Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?

Howdy, I've been developing a packet tunnel extension meant to run on iOS and MacOS. For development I'm using xcodegen + xcodebuild to assemble a bunch of swift and rust code together. I'm moving from direct TUN device management on Mac to shipping a Network Extension (appex). With that move I noticed that on some mac laptops NE fails to start completely, whilst on others everything works fine. I'm using CODE_SIGN_STYLE: Automatic, Apple IDs are within the same team, all devices are registered as dev devices. Signing dev certificates, managed by xcode. Some suspicious logs: (NetworkExtension) [com.apple.networkextension:] Signature check failed: code failed to satisfy specified code requirement(s) ... (NetworkExtension) [com.apple.networkextension:] Provider is not signed with a Developer ID certificate What could be the issue? Where those inconsistencies across devices might come from?