macOS DNS Proxy system extension makes device stop processing MDM commands until reboot

Question

Created 3h

Replies 0

Boosts 0

Participants 1

Hi,

I see an interaction issue between a DNS Proxy system extension and MDM on macOS: after some time the device stops processing MDM commands until reboot, while DNS filtering continues to work.

Environment:

macOS: 15.x / 26.x (reproduced on multiple minor versions)
App: /Applications/MyMacProxy.app
System extension: NEDNSProxyProvider as system extension
Bundle id: com.company.agent.MyMacProxy.dnsProxy
Deployment: MDM (SimpleMDM)
DNS proxy config via com.apple.dnsProxy.managed
Devices: supervised Macs

Steps to reproduce:

Enrol Mac into MDM.
Install MyMacProxy app + DNS proxy system extension via pkg and apply com.apple.dnsProxy.managed profile.
DNS proxy starts, DNS is filtered correctly, user network works normally.
After some hours, try to manage the device from MDM:

push a new configuration profile,
remove an existing profile, or
install / remove an app.

5.MDM server shows commands as pending / not completed.

On the Mac, DNS is still filtered via our DNS proxy, and general network access (Safari etc.) continues to work.
After reboot, pending MDM commands are processed and we can remove the app, profile and system extension normally.

This is reproducible on our test machines. What I see on the Mac in the “stuck” state

apsd is running:

sudo launchctl print system/com.apple.apsd
# job state = running

com.apple.mdmclient.daemon exists as a job but is not running:

sudo launchctl print system/com.apple.mdmclient.daemon

Abbreviated output:

system/com.apple.mdmclient.daemon = {
  ...
  state = not running
  job state = exited
  runs = 5
  last exit code = 0
  ...
}

So the MDM client daemon has exited cleanly (exit code 0) and is currently not running; its APS endpoints are configured.

Our DNS proxy system extension is still processing flows: we see continuous logging from our NEDNSProxyProvider, and DNS filtering is clearly active (requests go through our upstream).
systemextensionsctl list still shows our DNS proxy system extension as active.

From the user’s perspective, everything works (with filtered DNS). From the MDM server’s perspective, commands stay pending until the next reboot. After reboot, MDM behaviour is normal again.

Uninstall / cleanup (current approach, simplified)

We currently use an MDM‑delivered shell script that:

disables our DNS proxy configuration for the console user by editing ~/Library/Preferences/com.apple.networkextension.plist and setting Enabled = false for our DNSProxyConfigurations entries;
flushes DNS cache and restarts mDNSResponder;
unloads our LaunchDaemon / LaunchAgent for the host app;
kills the system extension process using pgrep -f "com.company.agent.MyMacProxy.dnsProxy" | xargs kill -9;
removes the extension binary from /Library/SystemExtensions/.../com.company.agent.MyMacProxy.dnsProxy.systemextension;
removes /Applications/MyMacProxy.app and related support files.

We currently do not call systemextensionsctl uninstall <TEAMID> com.company.agent.MyMacProxy.dnsProxy from MDM, mainly because of SIP and because we understand that fully silent system extension uninstall is constrained.

The MDM responsiveness issue, however, can appear even if we don’t run this aggressive uninstall script and just let the extension run for some hours.

Questions

Is it expected that a DNS Proxy system extension (managed via com.apple.dnsProxy.managed) can leave a device in a state where:

apsd is running,
com.apple.mdmclient.daemon is not running (last exit code 0),
DNS proxy continues to filter traffic,
but MDM commands remain pending until reboot?

Are there known best practices or pitfalls when combining:

DNS Proxy system extensions (NEDNSProxyProvider),
MDM‑distributed com.apple.dnsProxy.managed profiles,
and MDM app / profile management on recent macOS versions?

For uninstall in an MDM environment, what pattern do you recommend? For example, is it better to:

disable / remove the DNS proxy profile,
stop the NE configuration via NEDNSProxyManager from the app,
avoid killing the system extension or removing files from /Library/SystemExtensions immediately,
and instead require a reboot for full removal?

I can provide a sysdiagnose and unified logs (including nesessionmanager, mdmclient and our logs) from an affected machine if that would be helpful.

Boost