Browse Policies & Filtering
- Dashboard overview
- Insights overview
- Sites Overview - Network Deployments
- Policies Overview - Create and Edit
- Custom Lists overview
- Clients Overview - Device Agents and Profiles
- Users Overview - Directory Users and Personas
- Organizations Overview - MSP Tenant Management
- Lookup Tool Overview
- Query Log Overview
- Settings Overview - Account Administration
- Help & Support Overview
- Signing In - Login, 2FA, and Password Reset
- Two-factor authentication (2FA)
- Add system users (role-based access)
- Check domain classification with the Lookup Tool
- Configurable objects and their associations
- Configure notifications
- Working with organizations (multi-tenant)
- Working with policies
- Content categories
- Security categories
- Application categories (Zero Trust app management)
- Working with allow and block lists
- Zero Trust TLD Filters
- Safe Search explained
- Safe Search supported search engines
- YouTube Restricted Mode explained
- Custom block pages
- Prevent DNS bypass
- Don't mix DNS providers
- Active Directory group policies
- Entra ID group policies
- Tracking individual users
Don't mix DNS providers
Why pointing at ScoutDNS and another resolver (like 8.8.8.8) at the same time causes inconsistent filtering and reporting, and what to do instead.
[!IMPORTANT] Use ScoutDNS resolvers as both primary and secondary. Don’t mix ScoutDNS with a public resolver (
8.8.8.8,1.1.1.1) or with a domain controller IP in the same DNS list.
Routers, operating systems, and DHCP servers don’t strictly favor the “primary” resolver over the “secondary” one. Many implementations send queries to whichever resolver answered last fastest, sometimes the primary, sometimes the secondary, sometimes alternating per query.
If one of the resolvers in the list is not ScoutDNS, the consequences are:
- Inconsistent filtering. Some queries reach ScoutDNS (and get filtered), others go to the alternate resolver (and bypass policy).
- Incomplete logs. Only queries that hit ScoutDNS appear in the activity log. The other queries vanish from your visibility entirely.
- Cached answers conflict. The OS/router DNS cache may hold answers from the unfiltered resolver, masking what’s really happening.
What to do instead
In every DHCP option, router DNS field, or domain-controller forwarder list:
- Primary: ScoutDNS resolver IP 1
- Secondary: ScoutDNS resolver IP 2
Both IPs are visible in Admin Console → Help → IPs List. They route via anycast, so if one fails the other is reached automatically with no perceptible delay.
If you need internal-domain resolution (Active Directory, internal services), route those queries through the ScoutDNS Relay, which forwards internal lookups to your domain controller while sending public queries to ScoutDNS.