In this article

Network and endpoint administrators use this page to understand current limitations of DNS PreCheck in the Windows Roaming Client and how these behaviors may affect filtering, logging, and DNS routing in different environments.

DNS PreCheck is designed to improve reliability and compatibility by evaluating DNS locally before forwarding queries to the system resolver. While this behavior reduces traditional DNS conflicts, several known limitations remain in the initial release.

These issues will be refined in future releases.

Roaming Client and network policy overlap

If the Roaming Client is using DNS PreCheck and the device connects to a network that also uses DNSFilter as its DNS resolver—such as an office Wi-Fi network protected by Network Filtering—the device will receive both filtering policies:

• the Roaming Client policy, and
• the network-level Site policy

This is expected behavior. The DNS traffic is evaluated first by the agent on the device, and then again by the network resolver: DNSFilter just so happens to be that resolver. Users may report unexpected blocks if the two policies differ.

Because both enforcement points process the same DNS lookup, the DNS query log will show duplicate entries: one from the device (Roaming Client) and one from the network’s DNSFilter resolver. These entries represent two distinct filtering events, not an error, and will appear alongside other duplicate-looking queries generated by modern operating systems and browsers.

Filtering decision gaps on certain networks

On some networks, filtering decisions may not be received if the upstream device modifies or filters DNS packets.

Examples include:

• mesh routers that rewrite EDNS0 headers
• security appliances that strip EDNS0 metadata
• routers that alter DNS payloads (e.g., eero with advanced security features enabled)

DNS PreCheck currently relies on EDNS0 signaling for compatibility with these devices. A fallback mechanism will be introduced in a future release which is in-progress with our Engineering Team.

VPN or endpoint security conflicts

DNS PreCheck depends on the DNS resolver provided by the OS or VPN.

Some third-party applications intercept, encrypt, or redirect DNS traffic before the Roaming Client can evaluate it.

Common examples include:

• Zscaler
• FortiClient ZTA
• Certain zero trust or DNS filtering agents

These tools may prevent PreCheck from receiving or evaluating DNS queries, resulting in partial or missing filtering.

A maintained compatibility list is available in Software Compatibility.

Ignore VPN not supported in Custom Filtering mode

The IgnoreVpnInterfaces override is supported in Classic Filtering mode only. When the Windows Roaming Client is configured to use Custom Filtering (Transparent Proxy), this setting has no effect and VPN interface exclusions are not applied. This applies both to the override file setting and the in-app Site configuration setting. 

This is a current product limitation. If the environment requires both Custom Filtering mode and VPN interface exclusions, consider the following alternatives:

• Split DNS configuration. Configure the VPN client to resolve internal domains through its own DNS servers, bypassing the Roaming Client for those queries
• Classic Filtering mode. Supports IgnoreVpnInterfaces but may conflict with certain VPN clients

Configuration propagation delay

Changes made to the Connection and Filtering mode may take several minutes to apply to a Roaming Client running DNS PreCheck. This is expected due to the agent’s configuration polling interval.

If testing a new configuration, allow several minutes for changes to propagate.

Fail-open behavior

DNS PreCheck currently handles fail-open behavior by design.

Classic DNS Filtering does not yet support a configurable fail-open mode; configurable fail-open options will be added in an upcoming release.