DNS Proxy system extension – OSSystemExtensionErrorDomain error 9 “validationFailed” on clean macOS machine

You post is quite hard to read. I recommend that you review the advice in Quinn’s Top Ten DevForums Tips, and specifically the stuff about code blocks in tip 5.

What are the likely reasons for … extension category returned error

I discuss the concept of the extension category in this post. The rest of that thread should have some useful hints and tips.

Taking a step back, you’re clearly testing the direct distribution case here, that is, where the sysex uses Developer ID signing. I’d like to clarify the context for that:

• Do you already have this working with Apple Development signing? That is, this code is working at your desk but fails when you deploy it using Developer ID signing?
• Or is this the first time you’ve tested your code?

If it’s the latter, I recommend that you stop using Developer ID and instead switch to Apple Development. That’s a good idea in general — see The Care and Feeding of Developer ID for more on that — but in the case of an NE sysex it actively makes your day-to-day development easier. I explain this process in some detail in Debugging a Network Extension Provider.

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

Thanks for the pointers and links.

To answer your question: this is actually the first time I’m bringing up this NE system extension. I started directly with Developer ID because the final goal is MDM deployment, but I haven’t yet verified the setup with Apple Development signing.

I’ll now switch both the host app and the DNS Proxy system extension to Apple Development signing, follow the “System Extension Hints” and “Debugging a Network Extension Provider” flow (post‑build copy to /Applications, run from there, first‑light log in main.swift, attach debugger, etc.), and see if the provider can be started successfully in that configuration.

If I still get OSSystemExtensionErrorDomain error 9 / “extension category returned error” with Apple Development signing on a clean dev machine, I’ll update this thread with the exact steps, logs, and configuration.

I updated the App ID for the DNS Proxy system extension and noticed that Developer Portal only exposes the legacy dns-proxy value under Network Extensions. There is no option for dns-proxy-systemextension.

My extension’s entitlements currently contain:

xml <key>com.apple.developer.networking.networkextension</key>
<array>
<string>dns-proxy-systemextension</string>
</array>
When I create a Mac App Development provisioning profile for this App ID and try to use it for signing the system extension target, Xcode fails with:

Provisioning profile "Dev-Mac-App-DNSProxy" doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement.

So at this point the entitlements and the Developer Portal capabilities cannot be made to match: the profile only knows about dns-proxy, while my extension needs dns-proxy-systemextension.

Is dns-proxy-systemextension the correct entitlement value for a DNS Proxy packaged as a system extension today, and if so, how should this be represented/configured in the Developer Portal so that the Mac App Development profile matches the entitlement?

this is actually the first time I’m bringing up this NE system extension.

In that case I recommend that you switch to using Apple Development signing.

Using Developer ID for day-to-day development is a bad idea in general, as I explained in that other post, but it causes significant grief in the case of NE system extensions:

• If you’re using Xcode, you run into the entitlement suffix issue you’ve noticed. For more on that, see Exporting a Developer ID Network Extension.
• The system requires that Developer ID-signed system extensions be notarised, so you have to notarise your app before each test O-:

ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

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

Thanks for the clarification about Developer ID vs Apple Development and for the links.

Previously I started with Developer ID and the dns-proxy-systemextension entitlement, but per your advice I’ve now switched both the host app and the DNS Proxy system extension to Apple Development signing and the legacy dns-proxy value.

Current Apple Development setup

macOS: 15.7.3 (24G419)

Xcode: 26.2 (17C52)

Host: com.example.agent.MyMacProxy

DNS Proxy system extension: com.example.agent.MyMacProxy.dnsProxy

System extension entitlement:

xml <key>com.apple.developer.networking.networkextension</key> <array> <string>dns-proxy</string> </array> System extension Info.plist (built .systemextension inside the host app):

xml <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.system_extension.network_extension</string> <key>NSExtensionPrincipalClass</key> <string>MyMacProxy.DNSProxyProvider</string> </dict> There is no NetworkExtension key in this plist (confirmed with plutil -p on the built .systemextension in both DerivedData and /Applications).

The system extension is embedded at:

MyMacProxy.app/Contents/Library/SystemExtensions/com.example.agent.MyMacProxy.dnsProxy.systemextension

The host app (from /Applications) configures DNS Proxy via NEDNSProxyManager with:

swift providerBundleIdentifier = "com.example.agent.MyMacProxy.dnsProxy" What happens

If I add a NetworkExtension dictionary with NEProviderClasses and try different keys like:

dns-proxy

DNSProxy

NEDNSProxy

I consistently get Code=4 errors such as:

text Validating system extension com.example.agent.MyMacProxy.dnsProxy System Extension validation failed: Error Domain=NetworkExtensionErrorDomain Code=4 "The system extension com.example.agent.MyMacProxy.dnsProxy has an invalid extension point in its NetworkExtension key in its Info.plist: dns-proxy." If I then remove the NetworkExtension dictionary entirely (leaving only the NSExtension dict shown above), Code=4 goes away, but nesessionmanager still reports Code=2 about NetworkExtension needing to be a non‑empty dictionary, even though that key is no longer present in the current Info.plist.

I’ve tried:

removing the standalone .systemextension product (keeping only the embedded one)

systemextensionsctl uninstall <team> com.example.agent.MyMacProxy.dnsProxy and systemextensionsctl reset

killing nesessionmanager / systemextensionsd

rebooting and reinstalling the host app into /Applications

The behaviour doesn’t change.

Questions

For a DNS Proxy implemented as a Network Extension system extension under Apple Development signing, is the intended pattern to have no NetworkExtension dictionary at all (only NSExtensionPointIdentifier = com.apple.system_extension.network_extension plus the dns-proxy entitlement), or should DNS Proxy system extensions still declare a NetworkExtension dictionary with NEProviderClasses?

If a NetworkExtension dictionary is required, what are the currently valid keys for a DNS Proxy system extension (given that dns-proxy, DNSProxy, and NEDNSProxy all trigger Code=4 for “invalid extension point”)?

If you have a minimal, known‑good DNS Proxy system extension sample (Info.plist + entitlements) that passes this validation on current macOS, that would be extremely helpful as a reference.

Again, I’m struggling to read your post. Chunks of text are being munged because you’ve not put them inside a code block, which makes it hard for me to offer advice because I can’t tell whether the info I’m looking at is accurate. Please repost it with better formatting.

Earlier I mentioned Quinn’s Top Ten DevForums Tips. Please read it through, especially tip 5.

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

Thanks for the clarification about Developer ID vs Apple Development and for the links. Per your advice, I’ve switched both the host app and the DNS Proxy system extension to Apple Development signing and the legacy dns-proxy entitlement. Current setup macOS: 15.7.3 (24G419) Xcode: 26.2 (17C52) Host app bundle ID: com.example.agent.MyMacProxy DNS Proxy system extension bundle ID: com.example.agent.MyMacProxy.dnsProxy System extension entitlements:

<key>com.apple.developer.networking.networkextension</key>
<array>
<string>dns-proxy</string>
</array> 

System extension Info.plist (built .systemextension inside the host app):

<key>NSExtension</key>
<dict>
<key>NSExtensionPointIdentifier</key>
<string>com.apple.system_extension.network_extension</string>
<key>NSExtensionPrincipalClass</key>
<string>MyMacProxy.DNSProxyProvider</string>
</dict>

There is no NetworkExtension key in this Info.plist (confirmed with plutil -p on the built .systemextension in both DerivedData and /Applications). The system extension is embedded at:

MyMacProxy.app/Contents/Library/SystemExtensions/com.example.agent.MyMacProxy.dnsProxy.systemextension 

The host app (from /Applications) configures the DNS Proxy via NEDNSProxyManager with:

providerBundleIdentifier = "com.example.agent.MyMacProxy.dnsProxy"

What happens If I add a NetworkExtension dictionary with NEProviderClasses and try different keys like:

<key>NetworkExtension</key>
<dict>
<key>dns-proxy</key>
<array>
<string>MyMacProxy.DNSProxyProvider</string>
</array>
</dict>

(or DNSProxy, or NEDNSProxy as the key), I consistently get Code=4 errors, for example:

Validating system extension com.example.agent.MyMacProxy.dnsProxy
System Extension validation failed:
Error Domain=NetworkExtensionErrorDomain Code=4
"The system extension com.example.agent.MyMacProxy.dnsProxy has an invalid extension point in its NetworkExtension key in its Info.plist: dns-proxy."

If I then remove the NetworkExtension dictionary entirely (leaving only the NSExtension dictionary shown above), the Code=4 error goes away, but nesessionmanager still reports Code=2 about NetworkExtension needing to be a non‑empty dictionary, even though that key is no longer present in the current Info.plist. To try to reset state, I’ve done the following:

Remove standalone product, keep only embedded systemextension
(reconfigured build to only embed)
systemextensionsctl uninstall <TEAM_ID> com.example.agent.MyMacProxy.dnsProxy
systemextensionsctl reset
killall nesessionmanager
killall systemextensionsd
Reboot and reinstall host app into /Applications 

The behaviour does not change: either Code=4 if NetworkExtension is present, or Code=2 complaining about NetworkExtension even when it’s not in the current plist. Questions For a DNS Proxy implemented as a Network Extension system extension under Apple Development signing, is the intended pattern to have no NetworkExtension dictionary at all (only NSExtensionPointIdentifier = com.apple.system_extension.network_extension plus the dns-proxy entitlement), or should DNS Proxy system extensions still declare a NetworkExtension dictionary with NEProviderClasses? If a NetworkExtension dictionary is required, what are the currently valid keys for a DNS Proxy system extension? dns-proxy, DNSProxy, and NEDNSProxy all trigger NetworkExtensionErrorDomain Code=4 with “invalid extension point” in my tests. Do you have a minimal, known‑good DNS Proxy system extension sample (Info.plist + entitlements) that passes this validation on current macOS (15.7.3 / Xcode 26.2)? A small reference example would be extremely helpful to compare against my configuration. Share and Enjoy, and thanks again for your time!

After switching to the new DNS Proxy system extension extension point, I’m seeing a mismatch between the current Info.plist on disk and what nesessionmanager reports during validation.

Current Info.plist of the installed system extension:

plutil -p "/Applications/MyMacProxy.app/Contents/Library/SystemExtensions/com.example.agent.MyMacProxy.dnsProxy.systemextension/Contents/Info.plist"

{
"CFBundleIdentifier" => "com.example.agent.MyMacProxy.dnsProxy"
"CFBundlePackageType" => "SYSX"
"NSExtension" => {
"NSExtensionPointIdentifier" => "com.apple.dns-proxy"
"NSExtensionPrincipalClass" => "com_example_agent_MyMacProxy_dnsProxy.DNSProxyProvider"
}
"NSSystemExtensionUsageDescription" => "SYSTEM_EXTENSION_USAGE_DESCRIPTION"
...
}

There is no NetworkExtension key in this Info.plist. However, when the host app tries to activate the DNS proxy system extension, I still get:

Validating system extension com.example.agent.MyMacProxy.dnsProxy
System Extension validation failed: Error Domain=NetworkExtensionErrorDomain Code=2
"The system extension com.example.agent.MyMacProxy.dnsProxy has an invalid NetworkExtension key in its Info.plist: the value for the NetworkExtension key must be a non-empty dictionary."

Spotlight does not show any other copies of this bundle ID:

mdfind 'kMDItemCFBundleIdentifier == "com.example.agent.MyMacProxy.dnsProxy"'

no results

Is there any known caching behaviour in nesessionmanager or in the NetworkExtension validation logic that could cause it to keep expecting a NetworkExtension dictionary, even when the current Info.plist only declares the com.apple.dns-proxy extension point?

Thanks for the updated posts.

legacy dns-proxy entitlement [value]

To be clear, this isn’t a legacy value. This value is used for App Store distribution, both on iOS and macOS. It’s also used for development. The -systemextension suffix is used for direct distribution using Developer ID signing. Neither value is more legacy than the other.

As to what’s going wrong, you’ve tried a lot of different things and it’s hard to be sure what’s what at this state. However, this is problematic:

<key>NSExtensionPointIdentifier</key>
<string>com.apple.system_extension.network_extension</string>

And it suggests that you could do with some high-level guidance. The best place to get that is Xcode. Consider this sequence:

1. In Xcode 26.2, create a new project from macOS > App template. In my case I named it “Test812857”.
2. Then create a new target within that project, using the macOS > System Extension > Network Extension template. In my case I named it “MyProxy”.
3. When creating that target, select DNS Proxy from the Provider Type popup.

The resulting structure is not 100% what you need, but it’s quite close. Here’s are some fixes:

1. In the sysex target, switch to the Signing & Capabilities tab and remove the App Groups capability. You’ll likely want to add that back at some point, so you can register an XPC service, but it’s not necessary right now.
2. Configure the Network Extensions capability so that only DNS Proxy is checked.
3. Now switch to the Build Settings tab and add a value for the Privacy - System Extension Usage Description build setting.
4. On the left, select the sysex Info.plist and remove the NetworkExtension > NEMachServiceName property. Again, will likely want to bring this back at some point, but you don’t need it right now.
5. If you’re absolutely sure that you only want to deploy directly, rather than in the app store, select the app target, switch to the Signing & Capabilities tab, and remove the App Sandbox capability. Sandboxing of the container app is mandatory for App Store distribution but optional for direct distribution with Developer ID signing.
6. Add the Network Extension capability and check DNS Proxy.
7. Add the System Extension capability and fill in the usage field.

Note Step 7 sets the usage on the app, rather than the sysex. I believe that’s wrong, and the usage needs to be on the sysex. Hence step 3. I’ll file a bug about this at some point.

Now build the app to make sure there aren’t any build-time problems.

With the app built, let’s look at the built binary, starting with the app itself.

First there’s the entitlement claims:

% codesign -d --entitlements - Test812857.app 
…
[Dict]
    [Key] com.apple.application-identifier
    [Value]
        [String] SKMME9E2Y8.com.example.apple-samplecode.Test812857
    [Key] com.apple.developer.networking.networkextension
    [Value]
        [Array]
            [String] dns-proxy
    [Key] com.apple.developer.system-extension.install
    [Value]
        [Bool] true
    …

Note I’ve edited these listings to focus on the key bits.

As you can see, it has an App ID, and claims entitlements to install a DNS proxy NE sysex.

All of these entitlement claims are authorised by the profile:

% security cms -D -i Test812857.app/Contents/embedded.provisionprofile | plutil -p -
{
  …
  "Entitlements" => {
    "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test812857"
    "com.apple.developer.networking.networkextension" => [
      …
      4 => "dns-proxy"
      …
    ]
    "com.apple.developer.system-extension.install" => true
    …
  }
  …
  "ProvisionedDevices" => [
    …
  ]
  …
}

And you can tell that this is a development profile because it’s limited to a specific set of provision devices.

Note The profile authorises other values in the com.apple.developer.networking.networkextension, and that’s OK. The entitlements in the profile act as an allowlist. See TN3125 Inside Code Signing: Provisioning Profiles for lots of backstory here.

Finally, the app’s Info.plist:

% plutil -p Test812857.app/Contents/Info.plist
{
  …
  "NSSystemExtensionUsageDescription" => "This is just for testing (app)."
}

Here’s the app variant of the usage description.

Now let’s move on to the sysex, again starting with the entitlement claims:

% codesign -d --entitlements - Test812857.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.Test812857.MyProxy.systemextension   
…
[Dict]
	[Key] com.apple.application-identifier
	[Value]
		[String] SKMME9E2Y8.com.example.apple-samplecode.Test812857.MyProxy
	[Key] com.apple.developer.networking.networkextension
	[Value]
		[Array]
			[String] dns-proxy
	[Key] com.apple.security.app-sandbox
	[Value]
		[Bool] true
    …

And let’s check that they’re authorised by the profile:

% security cms -D -i Test812857.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.Test812857.MyProxy.systemextension/Contents/embedded.provisionprofile | plutil -p -
{
  …
  "Entitlements" => {
    "com.apple.application-identifier" => "SKMME9E2Y8.com.example.apple-samplecode.Test812857.MyProxy"
    "com.apple.developer.networking.networkextension" => [
      …
      4 => "dns-proxy"
      …
    ]
    "com.apple.developer.team-identifier" => "SKMME9E2Y8"
    …
  }
  …
  "ProvisionedDevices" => [
    …
  ]
  …
}

Finally, the Info.plist:

% plutil -p Test812857.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.Test812857.MyProxy.systemextension/Contents/Info.plist
{
  …
  "NetworkExtension" => {
    "NEProviderClasses" => {
      "com.apple.networkextension.dns-proxy" => "com_example_apple_samplecode_Test812857_MyProxy.DNSProxyProvider"
    }
  }
  "NSSystemExtensionUsageDescription" => "This is just for testing (target)."
}

Now we see the effective usage description, but also note the NEProviderClasses values. Specifically, the Swift module name, com_example_apple_samplecode_Test812857_MyProxy is super long because the module name is derived from the product name and the product name from the bundle ID.

I think that this will be enough to get your proxy to load. Lemme know how you get along.

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