ZIA DNS Control Part One • Resolution Architecture • Field Notes
Every other any rule was closed years ago. This one survived because it looks like plumbing.
Where this starts
These notes come from a real implementation covering three forwarding scenarios at once: endpoints on Z-Tunnel 2.0, branch sites on IPSec, and a guest network with no tunnel and no agent. Three populations, three different answers to the same question, which is how a name gets resolved and who is allowed to answer.
The part that is easy to underestimate is that none of this is configured in a policy screen. It is configured on the resolution path itself — forwarders, exclusions, locations — and the policy screens only become useful once that path is decided. This article is about the path. The next one is about the policy.
Note on scope: this article is descriptive rather than prescriptive. It sets out what each mechanism does and what it depends on. What the right design is for your environment depends on things no article knows.
Section one
Why DNS Control is worth touching
1. The oldest service in the building
DNS is usually one of the first things stood up in a network. It comes before the segmentation project, before the proxy, before the SIEM, before anyone writes the word “policy” on a slide. It has to, because until names resolve, nothing else can be tested.
Then it becomes a certainty, and certainties do not get reviewed. The rule allowing UDP and TCP 53 outbound to any destination is, in a large number of rulebases, the last any rule still standing. It survives every audit for the same reason: removing it looks like breaking the internet. Nobody wants to be the person who touched DNS on a Tuesday.
That hesitation is understandable and it is also the problem. New services arrive with authentication, inspection, logging and a named owner, because they are built in an era that expects all four. DNS was grandfathered in. Attackers read the same rulebase everyone else reads, and the way out of a network is rarely the newest control. It is the oldest assumption.
Taking control of DNS means touching the resolution path. Internal servers get reconfigured, forwarders change, and which names resolve where becomes a design decision instead of a default.
That is worth stating in the first paragraph rather than the fortieth, because it is the part that cannot be delegated to a portal. The fear of touching DNS is rational. The conclusion drawn from it, that DNS should therefore be left alone, is not.
2. The protocol everyone is currently too busy to look at
There is a second reason DNS keeps getting deferred, and it has nothing to do with DNS. Almost every organisation is now pointed in the same direction: adopt AI, build agents, connect models to data, ship something before the competition does. Attention is finite, and a protocol from 1983 that has not broken yet loses that competition every quarter.
The irony is that the new thing rests entirely on the old one. An agent calling a model endpoint resolves a name first. A workload retrieving a document resolves a name first. A service talking to another service across two clouds resolves a name first, several times, usually with no human anywhere in the loop. The AI programme does not reduce the number of headless things making DNS queries from inside the estate. It multiplies them.
So the security effort follows a familiar pattern. Enormous energy goes into governing the new layer — model access, prompt handling, data boundaries, agent permissions — while the layer underneath is still allowed to ask anyone anything. Building modern controls on an unreviewed core is not caution. It is deferral with better branding.
It is not worth installing cameras that can recognise an ant if the front door is standing open. The camera is not wrong. It is answering a question nobody needed answered yet.
3. What the project actually buys
Every implementation costs something, so it should be possible to say what it returns without using the word “posture”. Three arguments, in the order a business audience finds them convincing.
It closes a path that needs no administrative access
With unrestricted outbound DNS, an application can select a resolver outside the organisation’s intended resolution path. On a managed endpoint, changing the DNS server on the network adapter usually requires privileges. Switching on secure DNS in a browser’s own settings does not, and that is where the exposure actually lives: in applications that carry their own resolver rather than in the operating system configuration.
DoH makes that path harder to distinguish, because the exchange is carried inside TLS on port 443 where a legacy firewall sees an ordinary HTTPS session. Where that session is not forwarded to the service and inspected, DNS policy and DNS logging are bypassed for it. That does not automatically mean the web policy is bypassed as well: if the connection that follows still reaches the platform, URL filtering, cloud application control and firewall rules still apply to it. What is lost is the DNS layer itself, its record of what was asked, and the chance to end the transaction before a connection is opened at all. For populations whose web traffic never reaches the platform — guest networks among them — there is nothing downstream left to catch it.
Three things worth keeping distinct. DNS Control can identify and act on DoH services and tunnels as such. Seeing the queries carried inside a DoH session is a different matter and depends on TLS inspection. And neither of those is the same as the trusted resolver accepting DoH as a resolution endpoint, which it does not.
It reaches the populations nothing else touches
Client Connector covers the endpoints it is installed on. The web proxy covers what passes through the proxy. Servers, printers, IoT and OT devices, cloud workloads, agents and guest users will never have an agent installed on them, and in many designs they never traverse a tunnel either.
DNS is the broadest control plane this whole set has in common. Not every device depends on it in the same way, since static addresses, embedded resolvers and cloud-native service discovery all exist. It is also one of the few places where a device with no agent leaves a centrally readable record of what it was trying to reach. Firewall logs, NetFlow and DHCP will tell you an address was contacted. The DNS log tells you what the device thought it was contacting, which is a different and usually more useful fact.
It is the cheapest place in the chain to stop something
A decision at the DNS layer ends the transaction before the client opens a connection to the requested destination: no session with it, no handshake with it, nothing from it to decrypt. The DNS exchange is not itself free — it is a question and an answer, and over TCP or DoH it carries a session of its own — but the destination is never contacted, and that is where the saving is. It also applies to anything that starts from a name, not only to web browsing.
Two adjacent benefits belong in the same paragraph, because they are the ones that interest whoever signs the order. An answer served from the data centre that received the request, rather than from a distant central resolver, can reduce both the latency users report as “the internet is slow” and the geographically wrong answers that send someone to the wrong instance of an application. And where an organisation already pays for a third-party DNS security service, the resolver included in the subscription is a line item that can be re-examined.
4. What it costs
An article that lists only benefits is a brochure. The ledger has a second column.
| What you gain | What it costs |
|---|---|
| Inspection of a protocol currently allowed to any destination | An inventory of internal domains and resolver subnets before anything changes |
| Visibility over devices that will never run an agent | Configuration changes on the servers whose failure stops the entire company |
| A DNS evasion path closed, DoH included | TLS inspection has to be in place for the DoH half to work |
| Enforcement before the connection is opened | A phased rollout, starting with a technical group, not a global change window |
| Local resolution and geographically consistent answers | Licensing: the granular rules and the DNS Gateway features sit in the Advanced Cloud Firewall tier |
| A third-party DNS security subscription that can be re-examined | Every exception needs a named owner, like every other bypass |
Before changing resolution behaviour, confirm that the change cannot cut you off from the administration portal or from DHCP, and write the rollback down first. This is the one project where the way back has to exist before the way forward is tried.
5. What you will actually have to touch
Three surfaces, one per forwarding model, and each is a design decision rather than a checkbox.
Internal DNS servers. Where the corporate resolvers answer for clients, they are the ones that have to reach the service, and that means the forwarder configuration. It also means confronting a setting that quietly waits for its moment: the option to fall back to root hints when no forwarder answers. Section 7 takes that apart properly.
Endpoints running Z-Tunnel 2.0. This work was already covered in a previous article and there is no reason to repeat it. DNS requests can be carried in the tunnel and resolved by the Zscaler trusted resolvers, while selected domains are excluded and resolved by the DNS server on the endpoint adapter. For private resources that exclusion is not a workaround, it is the access path. The discipline that goes with it is worth re-reading before starting: a domain gets excluded because it has to resolve through an internal or private path, not because an application is failing. Those are different sentences, and only one of them is a reason. See Z-Tunnel 2.0: Sending Everything to Zscaler Is the Easy Part, sections 11 and 12.
Guests and workloads with no tunnel and no agent. These reach the service as a known location defined by their public source IP, with firewall control enforced on it. Everything that follows for them, including what a blocked user actually sees in the browser, depends on that one piece of configuration being correct.
Section two
How the resolution path works
6. Two questions that look the same and are not
A recursive query is a question with an obligation attached. The client asks its resolver for an address and expects an answer, not advice. Whatever work is required to produce that answer is the resolver’s problem.
An iterative query is the work. The resolver asks a root server, which does not know the address but knows who runs the top-level domain. It asks the TLD server, which also does not know, but knows who is authoritative for the domain. It asks the authoritative server, which finally answers. At every step, “I do not know, ask them” is a complete and valid response.
Endpoints almost never issue iterative queries. Resolvers almost always do, unless someone has told them to hand the work to somebody else. That single distinction decides which requests the trusted resolver can serve, which need a different treatment, and which fail in a way that looks like the platform is broken.
7. Four ways a Windows DNS server can answer
Where the DNS role sits on domain controllers, the server has four mechanisms and it tries them in order. They are not interchangeable, and only two of them produce traffic a cloud service can do anything with.
| Mechanism | What the server does | What leaves the building | Servable by the trusted resolver |
|---|---|---|---|
| Authoritative zone | Answers from data it holds | Nothing | Not applicable, and correctly so |
| Conditional forwarder | Sends a named domain to a named server | A recursive query to that server | Depends on the target, and usually should not be Zscaler |
| Forwarders | Sends everything unknown to an upstream resolver | A recursive query | Yes |
| Root hints | Resolves the name itself, from the root down | A series of iterative queries | No |
Conditional forwarders are how internal names stay internal. Corporate zones, partner domains, private cloud zones and split-brain records belong here, pointed at the servers that hold them. A public resolver has no business seeing those names, and in a split-brain design an external answer for an internal service is not a resolution failure. It is a resolution that is wrong in a way nobody notices until the traffic goes to the wrong place.
Root hints are the setting that waits. Where forwarders are configured, there is usually a companion option allowing the server to fall back to root hints when no forwarder answers. It exists to keep resolution alive during an upstream outage, which sounds prudent. What it actually does is change the type of query the server emits, from recursive to iterative, precisely at the moment something is already wrong. If port 53 is being sent to the trusted resolver, those iterative queries are discarded, resolution stops, and the incident is reported as a Zscaler outage.
The fallback to root hints is a design decision, not a safety net. Decide explicitly whether the internal servers are allowed to resolve on their own, and build the transit path described in section 10 if the answer is yes.
8. What the trusted resolver is, and what it is not
The trusted resolver is a recursive resolver service running in the Zscaler data centres alongside the service edges, included in the subscription. It caches answers for the time to live the response carries, validates DNSSEC, and answers from wherever the request arrived — which is what reduces both the latency of a distant central resolver and the geographically wrong answers.
What it is not matters just as much, because most design mistakes come from assuming otherwise.
- It is not a single global address in the style of the well-known public resolvers. There is no one IP to type into every DHCP scope in the company.
- It does not answer iterative queries. It expects questions from endpoints, so a query asking for a referral rather than an answer is treated as a misconfiguration and dropped.
- It does not support EDNS Client Subnet. Where an application needs answers geolocated to the client rather than to the data centre, requests have to go to a public resolver that supports client subnet instead.
- It does not terminate DoH tunnels, which is a separate matter from inspecting DoH traffic and worth keeping distinct in conversation.
Documented failure behaviour. If the DNS cluster in a data centre fails, requests are forwarded to a public DNS service. Requests that time out or return a server failure or a refusal are redirected to the geographically nearest anycast server. The DNS Insights log records which server actually answered, which is the first thing to check when an answer is surprising.
9. Two roads to the resolver
Implicit. A predefined destination NAT rule captures traffic to port 53 and sends it to the trusted resolver regardless of the address the client has configured. An endpoint still pointed at a well-known public resolver reaches the Zscaler one. Nothing changes on the endpoint, which is the main attraction. The cost is that the configured resolver and the answering resolver are different, which some compliance requirements do not accept and which reliably confuses whoever is troubleshooting at two in the morning.
Explicit. Zscaler publishes, for every data centre, a set of virtual addresses that can be configured directly as DNS servers on a client or on an internal forwarder. They are listed on the cloud configuration site under the GRE virtual IP column for the chosen data centre, and requests to port 53 on those addresses are answered by the trusted resolver. This is the option for organisations whose policy requires that the resolver configured is the resolver actually used. Take two of them, ideally from two different data centres.
What these addresses are. Service edge virtual addresses, not globally advertised public resolver addresses. Whether they answer a given query depends on the forwarding model in use, on the location configuration in the tenant, and on the source being recognised by the service.
Two resolver addresses remove the obvious single destination, but they do not by themselves define failover behaviour. Client operating systems and DNS servers differ in how they choose a resolver, how long they wait, when they retry and whether they return to the first one. Resolver redundancy and client-side behaviour are two separate tests.
For corporate populations this is still not the preferred path. Zscaler’s own recommendation is that DNS reaches the service through Client Connector on Z-Tunnel 2.0, or through GRE or IPSec, whenever that is possible. Endpoints already running Z-Tunnel 2.0 have no reason to be pointed at these addresses at all.
The tunnel-less exception, and who it belongs to
There is a documented path for sending DNS to the service without any tunnel, and it exists for a specific population: guest Wi-Fi, unauthenticated workloads, and sites where GRE or IPSec is genuinely not an option, including migrations away from a retired resolver service or a third-party provider. It is a recommended pattern for those cases, not a general alternative to a tunnel.
The shape of it is short. The client, or the DNS forwarder serving that segment, is pointed at the data centre virtual addresses. The site’s public IP is declared in the tenant as a static IP and attached to a location with firewall control enforced, so the service recognises where the queries come from. The predefined destination NAT rule is what actually hands the query to the trusted resolver, so it has to be present and enabled. Queries arriving from an address the tenant does not know are dropped, which is also what stops the rest of the internet from using the resolver on your behalf.
Two limits, stated up front. This path does not cover DNS over HTTPS, and it does not cover IPv6 DNS. Whatever a guest device does over those two, this design does not see.
Everything else in the estate stays inside the general rule. Corporate endpoints, branch users and internal servers reach the resolver through a tunnel. Treating the tunnel-less path as a shortcut available to the rest of the network is the kind of assumption that survives design review and fails in production.
There is a second-order benefit that comes with this model, and it applies exactly where it is needed. The receiving address is available as a policy criterion, so a single site with a single public IP can send guests and other unauthenticated populations to different data centre addresses and receive a different DNS policy for each, selected on the combination of source location and receiving address.
In this design, where the guest web traffic never traverses the platform, the DNS response is the only enforcement decision applied to the transaction.
10. Resolver, or transit to somebody else’s
Both models are supported and the difference is not about visibility. In both cases the request and the response pass through inspection, and policy applies to both directions.
In the resolver model the trusted resolver answers. Nothing else has to exist and nothing else has to be paid for. In the transit model the service acts as a DNS proxy to an approved external resolver, public or privately hosted on the internet. The request leaves with the service edge address as its source, which incidentally removes the organisation’s own addresses from the resolver’s view of the world, and the answer comes back through the same path where it can still be examined and acted on.
Transit is the right answer in a handful of concrete situations: a resolver holding records the organisation needs, a contractual or regulatory obligation to use a named service, an existing DNS security subscription that is not being cancelled this quarter, a requirement for client subnet support, and the iterative case below. It also moves the availability question onto that external resolver, which then needs the same redundancy thinking the trusted resolver would have had.
Letting an internal resolver do its own work
Where the decision is to let internal servers resolve from the root down, the iterative queries they emit have to be allowed to transit the service and reach servers that will answer them. Left alone they are captured by the redirection to the trusted resolver and discarded, because the trusted resolver has no way to respond to them.
The mechanism is a destination NAT rule ranked above the predefined one, matched on the source addresses of the internal DNS servers, translating to port 53 without rewriting the destination. The query then continues to whatever it was already asking: root, top-level domain, authoritative server. Nothing about inspection changes. Requests and responses are still evaluated against DNS policy. Where every DNS request arriving at the service is iterative, or where the decision is to send everything to an external provider, the predefined redirection can be disabled outright instead.
Two consequences belong in the design document rather than in someone’s memory. The trusted resolver is no longer in the path for that traffic, so local resolution, caching and the geographic benefits do not apply to it. And the rule has to be scoped by source address, because a rule that transits all DNS transits all DNS, and the traffic that was supposed to reach the trusted resolver quietly stops doing so.
One clarification before the next article. This rule lives in the NAT Control tab of the firewall, not in the DNS Control policy, and that is where most of the confusion in real deployments sits. Two planes, two jobs: NAT Control decides where a DNS query is allowed to go and who ends up answering it, DNS Control decides whether the exchange is permitted and what the client receives back. A working design needs both, configured in that order.
11. What each path lets you write policy on
The last thing this article has to establish is the one that changes what is possible later.
| Path into the service | Source the service sees | Criteria available | Resolution performed by |
|---|---|---|---|
| Client Connector on Z-Tunnel 2.0 | The endpoint, with its user context | Users, groups, departments, locations, time | Zscaler, for names not excluded |
| Clients at a site over GRE or IPSec | The endpoint, behind the location | Users where authentication applies, locations, time | Zscaler |
| Internal DNS servers forwarding | The DNS server, and only the DNS server | Locations and time | Zscaler |
| Internal DNS servers resolving iteratively | The DNS server | Locations and time | The internet, in transit |
| Guests sent tunnel-less from a known location | The location’s public address | Locations, time, receiving address | Zscaler |
Consolidating resolution behind internal forwarders is a perfectly reasonable design. It just costs attribution, and the cost is total: from the moment the forwarder takes over, every request in the logs belongs to the DNS server, and no DNS rule written afterwards can recover the name of the person who asked. This is the same boundary described in The Location Is Not a User, arriving from a different direction.
Decide the resolution architecture with the policy you intend to write already in mind. The order is not reversible.
Final thoughts
DNS Control is not a filtering feature that happens to sit in the firewall menu. It is the decision to stop treating name resolution as infrastructure and start treating it as a control surface with an owner, a policy and a log.
The work is not in the policy screens. It is in the resolution architecture: which servers forward and where, which names stay internal, which populations arrive through a tunnel and which one does not, and whether the answer comes from the trusted resolver or from somewhere else chosen deliberately. Every one of those decisions constrains the policy that can be written afterwards, which is why they belong before the first rule rather than after the first incident.
The goal is not to say “we enabled DNS Control”. It is to say that a protocol previously allowed to any destination is now inspected, attributed wherever attribution is possible, and answered by a resolver we chose.
The next article goes to the configuration itself: firewall enablement on locations, the NAT Control tab and the DNS Control policy in the order they have to be built, rule structure and evaluation, tunnels and encrypted DNS, the record types worth suppressing, what a blocked user actually sees, and the rollout sequence.
Sources and references
- Zero Trust Navigator — Z-Tunnel 2.0: Sending Everything to Zscaler Is the Easy Part
- Zero Trust Navigator — The Location Is Not a User: How ZIA Decides Who Sent the Traffic
- Zscaler Help — About DNS Control
- Zscaler Help — Best Practices for DNS Control Rules
- Zscaler Help — Configuring the DNS Control Policy
- Zscaler Help — About NAT Control
- Zscaler Help — Handling DNS Resolution for Various Traffic Forwarding Methods
- Zscaler Help — About DNS Gateways
- Zscaler Help — About EDNS Client Subnet (ECS) Injection
- Zscaler Help — Zscaler Service Endpoints
- Zscaler Reference Architecture — DNS Security and Control
- Zscaler Zenith Community — Tunnel-less DNS Resolution using DNS Control and ZTR
- Microsoft documentation on DNS forwarders, conditional forwarders and root hints.
- Figures 1 to 9: original Zero Trust Navigator diagrams.
Behaviour described here follows Zscaler’s published documentation except where explicitly noted otherwise. Product behaviour changes; verify against current documentation before relying on any of it in a design.