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.
Short Hostnames in Local Domains
As of 30 September 2025 Local Domains configured for Roaming Clients can be both short hostnames (e.g., printer-1, serverA) and fully qualified domain names (FQDNs) (e.g., printer-1.office.local).
- Short hostnames may only work inside the local network and can conflict across different networks
- For reliability, use FQDNs whenever possible. Reserve short hostnames for cases like printers or IoT devices, and test locally to confirm resolution
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:
| Source | Type | Scope |
|---|---|---|
| Primary DNS suffix | Static, Active Directory, or Group Policy | Global |
| Connection-specific suffix | DHCP or manual | Per-interface |
| Global search list | Registry | Global |
| GPO search list | Group Policy | Global |
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
Comments
0 comments
Please sign in to leave a comment.