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.

Recommended configuration¶

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.

DNSFilter recommend using Windows Name Resolution Policy Table (NRPT) rules (Microsoft NRPT Documentation). 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.

Enclave's local stub resolver binds to the system's virtual adapter IP address, which is unique to each enrolled system, so the command below uses enclave get-ip to resolve the correct address automatically:

Add-DnsClientNrptRule -Namespace ".enclave" -NameServers "$(enclave get-ip)"

Add an NRPT rule for each Enclave-managed zone. If you use custom DNS zones, repeat the command for each zone suffix. To verify the rules are applied:

Get-DnsClientNrptRule

For further details, refer to DNSFilter's guide to using Enclave with Windows Roaming Client documentation.