With adam:ONE® Zero Trust connectivity policies (aka allowlisting/whitelisting) there’s an order of operations, and as soon as there’s a match, it exits rule-processing:
- Authoritative Entries. When the muscle is authoritative for a fully-qualified domain name, say nas.anycorp.io, then there’s no reason to consult any other rule.
- Forwarding Rules. Domains such as Active Directory domains to be forwarded to controllers.
- Block Rules. Any domains set to be blocked by static or smart rules.
- Allow Rules. Any domains allow-listed/white-listed.
- Reflex Rules. Any domain permitted to be resolved by an allowed category.
- DNS Resolver processing.
For any and all domains arriving at DNS Resolver processing, they are ready to get answers. Unless otherwise specified, adam:ONE® will consult System DNS, which in FreeBSD and Linux systems is typically found at:
/etc/resolv.conf
It is typical that system administrators use 1.1.1.1 and 1.0.0.1 so the content usually looks like this:
nameserver 1.1.1.1
nameserver 1.0.0.1
search lan.anycorp.io
In a multi-WAN environment on pfSense®, make sure the Monitor IP is different from the name servers you use:
If your Monitor IP is the same as a system resolver, there will always be a static route that won’t fail over from ISP1 to ISP2. The result is that upstream DNS fails.
Additional Resilience
Although the quads are not often down, it can happen. For additional redundancy, use DNSharmony as your resolver on your policy like this:
