Don't mix DNS providers

[!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.

Related

• ScoutDNS resolver IPs
• Quickstart: WAN forwarding
• Relay setup and configuration