In this article

Network administrators use this article to understand how internal domains and DNS resolvers are handled by DNSFilter services, including Roaming Clients and Relay deployments.

Why local domains and resolvers matter

Many networks use internal DNS zones for resources such as file shares, domain controllers, authentication services, printers, and custom applications. These internal names may use fully qualified domain names (FQDNs), short hostnames, or .local suffixes.

Correct operation requires these internal names to be resolved by the internal network’s DNS servers. If they are not routed properly:

• Intranet pages fail to load
• Shared drives or printers do not respond
• Authentication to Active Directory fails
• Applications that rely on internal DNS return errors

DNSFilter must correctly distinguish internal DNS queries from external DNS queries to preserve normal network behavior.

How DNSFilter handles local domains across platforms

With the introduction of Connection and Filtering modes, internal DNS handling depends on the interception method used by the deployment and whether requests are routed by the operating system or by dashboard configuration.

On Windows v3.0 and higher, local traffic is handled differently depending on the configuration:

• Transparent Proxy + DNS PreCheck relies on the device's own resolvers—no dashboard configuration required
• Transparent Proxy + Classic DNS Filtering uses dashboard-configured local domains to determine which queries route to internal DNS servers. Local resolvers are not used in this configuration
• DNS Loopback (Classic DNS Filtering) may use both dashboard-configured local domains and local resolvers

The macOS, iOS, and Android agents, as well as the DNS Relay, require dashboard-configured local domains and resolvers to handle local services.

Chromebook Roaming Client local domains are managed in the Google Admin dashboard.

When manual local domain configuration may not be needed (Windows)

On Windows, the Roaming Client can automatically detect domains that require local DNS context based on system configuration. In most environments, if the endpoint is properly configured via DHCP, Active Directory, or Group Policy, manual local domain configuration is not required.

The agent recognizes local domain context from the following sources:

LocalDomainFallbackEnabled (Windows Classic DNS Filtering, v3.8.15 and later)

When the Roaming Client sends a local-domain query to the local resolver and does not receive a confirmed answer (no record, an error, or no response), it asks DNSFilter's resolvers instead. This setting defaults to true, preserving the same behavior as versions before 3.8.15.

To disable the fallback, add to appsettings.overrides.json:

{ "LoopbackProxy": { "LocalDomainFallbackEnabled": false } }

When to turn it off:

• The same domain exists publicly. If corp.example.com has internal records on the local DNS servers and public records on the internet, a lookup the local resolver cannot answer gets a public answer from DNSFilter, so users are sent to the public address instead of the internal one.

• Internal hosts with IPv4 records only. Devices look up both IPv4 (A) and IPv6 (AAAA) addresses. If an internal host has no IPv6 record, that half of the lookup goes to DNSFilter, which can return a public address or a block page for a name that should only exist internally.

When to leave it on:

When devices sometimes cannot reach the local resolver but still need to resolve names under that domain (for example, remote users off VPN whose internal domain also hosts public services).

Special-case domains handled automatically

In addition to configured suffixes, the Roaming Client recognizes certain domains as requiring local handling regardless of dashboard configuration.

Multicast DNS (mDNS)

The .local suffix is automatically forwarded to a local resolver.

Reverse DNS

PTR queries for the following private and local IP address ranges are automatically sent to local DNS servers:

• 10.in-addr.arpa
• 16.172.in-addr.arpa through 31.172.in-addr.arpa
• 168.192.in-addr.arpa
• 100.51.198.in-addr.arpa
• 113.0.203.in-addr.arpa
• 8.b.d.0.1.0.0.2.ip6.arpa

Related support content

• Resolve VPN and Windows agent conflicts 
• Fix blocked traffic that doesn’t show up in the DNS Query Log (unknown page)
• Configure firewall EDNS rules to allow local resolution