In this article
DNSFilter transitioned the macOS Roaming Client from DNS interception via loopback (127.0.0.1) to an Apple NEDNSProxyProvider System Extension — the NetworkExtension framework's supported mechanism for DNS filtering on macOS. As Apple began phasing out unsupported interception methods in macOS 11 and beyond, this shift ensured continued compatibility, improved reliability, and long-term support across modern macOS environments.
The legacy approach: Loopback
The original Roaming Client (1.x) used a loopback interface to intercept and filter DNS traffic. This involved redirecting DNS requests to 127.0.0.1, where the agent inspected the traffic and enforced policies.
While effective for many years, this approach relied on undocumented and unsupported behaviors in macOS networking.
Apple began deprecating and restricting loopback interception methods starting with macOS 11 Big Sur, released in November 2020, introducing security controls that made this technique fragile and unreliable.
What happened
macOS 11 Big Sur introduced significant changes to system security and networking, including:
- Enhanced System Integrity Protection (SIP)
- Increased enforcement of signed and notarized system extensions
- Early limitations on legacy methods such as redirecting traffic to
127.0.0.1(loopback)
These restrictions became stricter with each subsequent release:
- macOS 12 Monterey (2021): tightened enforcement of DNS resolution paths
- macOS 13 Ventura (2022): further reduced support for non-System Extension network interception, breaking loopback-based filtering under some conditions
While loopback may have appeared to work intermittently past Big Sur, Apple has established that the NetworkExtension and System Extension frameworks are the only supported methods going forward.
The Apple-compliant approach: System Extension
The updated agent runs as a System Extension using Apple's NEDNSProxyProvider API, part of the NetworkExtension framework, which intercepts and processes DNS queries at the OS level. This is the same framework used by enterprise security tools across the industry. DNS queries pass through this extension before reaching any resolver, giving DNSFilter accurate, reliable visibility into all DNS activity on the device.
This provides greater stability, better performance, and continued compatibility with current and future versions of macOS.
Why MDM profiles are required
Apple gates System Extensions behind explicit approval because they run in a privileged context with direct access to OS-level network flows. A silent install therefore relies on a set of configuration profiles delivered through MDM: one pre-approves the System Extension so macOS loads it without prompting the user, one tells macOS which extension to activate as the DNS proxy, and additional profiles supply the certificates the agent needs.
Without these profiles, macOS prompts the end user to approve the extension manually, and on macOS 15 and later that prompt appears in System Settings under General, then Login Items & Extensions. Deploying the profiles through MDM before the agent installs suppresses these prompts entirely.
Why the change to Apple's standard
- Loopback interception was losing reliability. Starting with macOS 11, Apple progressively restricted the undocumented behaviors that 1.x depended on. By macOS 13 Ventura, loopback-based filtering broke under specific conditions. This was not a DNSFilter-specific issue; any DNS security tool relying on loopback redirection faced the same erosion
-
NetworkExtension is the only supported interception path. Apple's
NEDNSProxyProviderAPI is the documented, entitlement-gated mechanism for DNS filtering on macOS. The agent's behavior is now defined by a stable API contract rather than undocumented OS internals -
MDM integration is first-class. System Extensions are designed for enterprise deployment. The
com.apple.system-extension-policyandcom.apple.dnsProxy.managedMDM payload types give IT teams explicit, auditable control over which network extensions are active on managed devices - User-facing prompts are suppressible. With loopback, the agent required no approval but offered no MDM control. With System Extensions, MDM-managed devices get fully silent deployment, and unmanaged devices receive clear, OS-standard prompts
macOS compatibility timeline
Minimum supported macOS version: macOS 15 Sequoia or later is required. The agent is a universal build and supports whatever hardware Apple supports for each macOS version. macOS Roaming Client 1.x is end of life. See Application end-of-life policy for details.
- macOS 15 Sequoia (2024): Supported, validated on RC macOS 2.4.4. The System Extension approval UI moved to System Settings under General, then Login Items & Extensions. Apple introduced a new Local Network Privacy permission that may trigger a separate user prompt for apps accessing local network resources
-
macOS 26 Tahoe (2025): Supported, validated on RC macOS 2.4.6. Introduces the
NEURLFilterURL Filtering API - macOS 27 Golden Gate (2026): Supported, validated on RC macOS 2.4.7. Apple Silicon only — Intel Macs cannot upgrade past Tahoe
Technical features and differences
| Feature | 1.x Loopback | 2.x System Extension |
|---|---|---|
| Interception method | Localhost redirection | Apple NEDNSProxyProvider (NetworkExtension) |
| Apple support | Unsupported | Fully supported |
| Reliability | Decreasing on new macOS | High, OS-integrated |
| Performance overhead | Higher | Lower |
| MDM and enterprise controls | Limited | Robust |
| Extension UI location | Not applicable, no system extension | macOS 15 and later: System Settings, General, Login Items & Extensions |
| Intel Mac support | Supported | macOS 27 Golden Gate requires Apple Silicon |
| Future compatibility | Risky | Aligned with Apple roadmap |
Comments
0 comments
Please sign in to leave a comment.