AdGuard Home + Blocky → Zscaler DNS
AdGuard Home + Blocky ↔ Zscaler DNS: integration to migration path.
DNS is load-bearing — break LAN resolution and nothing on the network finds anything. So AdGuard Home and Blocky go live behind Zscaler DNS Control first, resolving alongside it while ZIA keeps validating every query, and only take over the LAN one subnet at a time. No flag day, no forced re-credentialing, and every phase rolls back in minutes.
The honest end state is partial: ZCC roaming and ZTNA-tunneled clients stay on Zscaler permanently, and the entire ZIA web tier — SSL inspection, URL filter, DLP, CASB — is never touched. We say so up front, because the rest of this only matters if you can trust it.
The idea
Resolve behind Zscaler first. Retire ZIA DNS per segment last.
The topology that makes this zero-downtime is split-horizon forwarding: DHCP option 6 hands clients a keepalived VRRP VIP fronting two AdGuard Home nodes plus Blocky, which resolve their own filter lists locally and forward everything else upstream to Zscaler DNS Control — so OSS becomes your LAN resolution layer without dropping ZIA's policy plane. Because the AGH egress is a known ZIA location, DNS Control rules keep applying. Internal zones route to your AD domain controllers via conditional forwarders, AGH gives you real per-client visibility and Blocky gives you Prometheus-native metrics — then, segment by segment, we decide whether to keep ZIA as the upstream or cut it to a recursive resolver, each decision independently and reversibly.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We read the current posture: the ZIA resolver IPs in use, your DNS Control rule export, custom URL categories used as deny lists, every internal zone, the ZCC-installed population per location, and 30 days of NSS DNS feed. Read-only.
Stand up AGH + Blocky in parallel
Two AdGuard Home nodes plus Blocky come up in HA behind a keepalived VRRP VIP, forwarding upstream to Zscaler with starter blocklists and conditional forwarders for every internal zone. No production DHCP scope points at them yet — we prove the path with synthetic load.
Cut a single low-blast-radius subnet
One non-prod subnet — a lab VLAN, guest, or single floor — has its DHCP resolver pointed at the AGH VIP. It resolves via AGH, which still forwards upstream to Zscaler, so ZIA keeps seeing the queries from the AGH egress IP.
Wave-migrate the LAN subnets
Every LAN subnet at the location moves to the AGH VIP in sequenced waves — lab and dev first, then general office, then finance, exec and latency-sensitive lines of business. Each wave gets a 48-hour soak and a ticket-and-verdict review before the next. ZCC roaming users are untouched.
Decide ZIA's role per segment
For each segment we record a decision: keep Zscaler as the upstream where ThreatLabZ coverage and audit-friendly NSS are required, or cut it where the ZIA web tier's SSL inspection and URL filter already cover the threat. Cut segments move their upstream to a recursive resolver, with ZIA DNS Control set monitor-only as an evidence window.
Retire ZIA DNS where cut
ZIA DNS Control is disabled for the cut segments after their monitor-only soak. It stays live for keep segments, for all ZCC roaming, and for every ZTNA / ZPA-tunneled client. The ZIA SKU is re-evaluated — full retirement of ZIA DNS is partial, not total, in almost every real deployment.
Steady state & operations
AGH and Blocky run LAN DNS for the documented segments while ZIA DNS Control runs the rest plus ZCC and ZPA. The runbook covers upgrades, blocklist refresh, retention review per regime, block-page customisation, intel-feed cadence, and DR rebuild from config plus data backup.
Feature parity
Where the OSS pair matches Zscaler DNS, and where it does not.
| Capability | AdGuard Home + Blocky | Zscaler DNS | Parity |
|---|---|---|---|
| DNS blocking / sinkhole | AGH filter lists plus Blocky blackLists (NXDOMAIN or custom redirect) | ZIA DNS Control deny rules | At parity |
| Blocklist sources | AGH filters plus Blocky blackLists (OISD, Hagezi pro+TIF, 1Hosts, StevenBlack) | ZIA Custom URL Categories (UI/API); vendor threat feeds | Partial |
| Category taxonomy | Provenance / filter-list tagging only | ZIA vendor URL taxonomy (~120 categories) | SaaS only |
| Threat intel ingest (STIX / MISP) | MISP / Falcon Intel via a STIX-to-hosts converter into AGH file:// filters | No native STIX / TAXII ingest | OSS only |
| Encrypted DNS (DoH / DoT / DoQ) | AGH native DoH/DoT/DoQ server and client; Blocky DoH/DoT | ZIA DoH at dns.zscaler.net/dns-query; DoT | Partial |
| Roaming / off-network client | None (LAN-bound; needs a DoH token plus MDM) | ZCC roaming DNS via tunnel, SAML-bound identity | SaaS only |
| Per-user (SAML) policy | Network-identifier only (clients.persistent MAC/IP/ClientID) | ZIA SAML-bound per-user DNS policy | SaaS only |
| Passive-DNS / threat intel | None | ZIA ThreatLabZ NRD/DGA feeds; Sandbox-fed DNS verdicts | SaaS only |
| SSL inspection | Out of scope (DNS-only) | ZIA SSL inspection (web tier, not DNS) | SaaS only |
| Logging / reporting | Self-owned querylog.json plus Blocky MySQL/Postgres; Prometheus /metrics | ZIA NSS feed to SIEM; tenant retention SKU-bounded | Partial |
| API surface | AGH /control/* REST; Blocky config-driven | ZIA API (/api/v1/dnsRules, /api/v1/urlCategories) | At parity |
| Deployment & HA | keepalived VRRP / anycast /32 / k8s Deployment | ZIA PoP anycast, vendor-managed | Partial |
| Cost model | Compute plus ops only (2× VMs or pods) | Per-seat ZIA DNS SKU, often bundled | Partial |
| Compliance (SOC 2 / ISO) | Self-owned controls; auditor must accept self-hosted DNS | ZIA SOC 2 / FedRAMP attestations inherited from vendor | SaaS only |
What we're honest about
The caveats most vendors leave out.
This is DNS only — the ZIA web tier stays
AdGuard Home and Blocky are DNS resolvers; they do nothing at the URL layer. Zscaler's SSL inspection, URL filter, DLP, CASB, Sandbox and Tenancy Restriction all live at the web tier and are never touched by this migration. Anyone who thinks a DNS move lets them retire ZIA wholesale is conflating two different things — we document the boundary explicitly so the threat path stays covered.
Roaming and per-user policy stay on Zscaler
AGH and Blocky have no native roaming client and no SAML-bound per-user policy — they identify clients by MAC, IP or ClientID. That is why the end state is partial: ZCC laptops off-LAN, ZPA-tunneled clients and BYOD keep ZIA DNS via the ZCC tunnel, with identity tied to the SAML user. The retirement target is the LAN, not the whole tenant.
No vendor taxonomy, passive DNS, or attestations
Zscaler ships roughly 120 vendor URL categories with an SLA, ThreatLabZ NRD and DGA feeds, Sandbox-fed DNS verdicts, and SOC 2 / FedRAMP attestations. OSS gives you provenance-tagged filter lists instead. ThreatLabZ-curated DGA, NRD and fast-flux detection outruns stacked OSS feeds, which lag and run a higher false-positive rate — we accept that residual gap only where the ZIA web tier still covers the threat downstream.
Self-hosting means you own uptime and the audit
Once ZIA DNS is cut for a segment, an AGH or Blocky outage is a LAN DNS outage with no managed fallback, and your auditor inherits self-hosted DNS inside the SOC 2 / ISO boundary. We run at least three nodes across two fault domains, an externally-probed uptime monitor, a break-glass DHCP fallback, crash-safe MySQL or Postgres query logs, and at least one audit cycle of overlap before ZIA-as-control is retired.
Why this beats a flag day
Reversible at every step, with a real soak before anything is cut.
Every phase rolls back in under 15 minutes while the parallel path is live — a DHCP option 6 revert, an upstream flip, or deleting nodes nothing trusts — and the one heavier step, re-enabling ZIA DNS Control after a cut, rolls back in under 30 minutes. And before DNS Control is disabled for a segment, that segment holds through a monitor-only soak of at least 30 days with no IR-flagged miss and tickets at or below baseline. A flag day gives you neither; this gives you both.
See whether your LAN DNS migrates cleanly.
A 30-minute call with a senior network engineer. We map your subnets, internal zones, and ZCC roaming population, decide per segment whether to keep Zscaler upstream or cut it, and tell you honestly where OSS DNS matches ZIA and where the web tier still has to carry the threat — before you commit to anything.
Map my migration →