Skip to content

Enclave and DNSFilter

DNSFilter is a cloud-delivered DNS security and filtering product. Unlike the upstream filtering services covered elsewhere in this section, DNSFilter is most commonly deployed via its Windows Roaming Client (or equivalent macOS agent), which runs on the same host as the Enclave agent and intercepts DNS traffic locally so that filtering policy can be applied wherever the device is used.

When both products are installed on the same host, each operates its own stub resolver and the two end up competing for the same DNS traffic from the operating system. A common symptom is that Enclave-managed names (hostnames in the .enclave zone, or in any custom zones you have created) fail to resolve, even though Enclave and DNSFilter both otherwise appear to be running correctly.

Why Enclave names may not resolve

Enclave's local stub resolver is designed to be cooperative. When it cannot answer a query locally and no connected Gateway can resolve the name either, it returns a SRVFAIL response (see Stub resolver query order for the full precedence). SRVFAIL is a deliberate cue that tells the operating system to fan out to other configured resolvers, including a DNSFilter stub running on the same host. Enclave's local stub resolver will therefore happily defer to an alternative resolver for any name it does not own.

DNS filtering products commonly take the opposite stance. Because their value depends on being the authoritative voice on whether a domain is allowed, they typically respond with NXDOMAIN or a sinkholed NOERROR for blocked or unknown names. The operating system treats both responses as definitive and will not fan out to any other resolver. This is a deliberate design choice on the part of these products, since a security stub that fanned out to another resolver would be trivially bypassable.

The practical consequence is that if the DNSFilter stub is questioned first and the queried name is not one DNSFilter expects to forward to a local resolver, Enclave's local stub resolver will never see the query, and Enclave-managed names will fail to resolve.

Because Enclave's local stub resolver is designed to interoperate with other resolvers regardless of ordering, the configuration work needs to happen at the operating-system level or on the DNSFilter side: each query for the Enclave-managed namespace (the .enclave zone and any custom zones you have created) needs to reach Enclave's local stub resolver on the Enclave Virtual Adapter, rather than being answered by DNSFilter.

For Enclave specifically, DNSFilter recommend using Windows Name Resolution Policy Table (NRPT) rules. NRPT is a Windows DNS routing mechanism that takes effect before the stub fan-out, so a rule that targets the .enclave suffix (and each of your custom zone suffixes) at the Enclave Virtual Adapter's address will cause those queries to bypass DNSFilter entirely and be sent directly to Enclave's local stub resolver. All other traffic is unaffected and continues to flow through DNSFilter as normal.

Refer to DNSFilter's documentation for the current recommended configuration and for alternatives such as local-domain forwarding, VPN-adapter exclusion, and split-tunnel guidance:

Last updated April 14, 2026