I turns out that ASAuthorizationController accepts data in raw format, meaning Base64URL should first be decoded, then sent into the controller, and the output should be encoded back into Base64URL

Never mind, there was a quirk with the macro implementation

When trying something like class PacketTunnelProvider: NEPacketTunnelProvider {     override func startTunnel(options: [String : NSObject]?, completionHandler: @escaping (Error?) -> Void) { let networkSettings = NETunnelNetworkSettings(tunnelRemoteAddress: "127.0.0.1") setTunnelNetworkSettings(networkSettings) { error in debugPrint(error)         completionHandler(error)         } I get the following error: Error Domain=NETunnelProviderErrorDomain Code=1 \"NEPacketTunnelNetworkSettings must be used with NEPacketTunnelProvider\" UserInfo={NSLocalizedDescription=NEPacketTunnelNetworkSettings must be used with NEPacketTunnelProvider}

You mean NEDNSSettings? If so, implementing a DNS proxy is a lot of work just to get that in-app control. Yes, exactly that. Seems like NEDNSProxyProvider is not a solution for the problem... `

@eskimo Thanks for your reply. There's less mess in my head now) Regarding the high-level task I'm trying to achieve: basically, I need DNS settings but with an in-app on/off toggle. And since the use of dns settings requires the user to go into settings app, using that approach is a no-go. I'm well aware of MDM requirement when it comes to DNS proxy, that's not a problem.

@meaton, the steps you have provided did get the expension up and running. Thanks But can you please explain a bit more about serverAddress. I don't understand fully how DNS works it seems. My idea was that with DNS Proxy one can intercept DNS requests and modify them (for example, route dns resolution requests to different dns servers based on some set of rules). So why does one need to point the proxy traffic towards some specific server? And what kind of server should that be?

Figured out what to do using on demand rules described here: https://www.wwdcnotes.com/notes/wwdc20/10047 . It turns out that the rules are evaluated one-by-one, and the .neverConnect means that the matching request is handled by the default DNS provider, not our custom one (which is exactly what I need)

@eskimo Hello. Has this one been fixed?

@meaton You'll want to provide some sort of serverAddress for NEDNSProxyProviderProtocol. Is this the same "https://my.dns.server/dns-query" one would use with NEDNSOverHTTPSSettings?