DNS Control deployment architectures, options

[Stefan_Sebastian]

The DNS Control module provides DNS security and DNS performance capabilities in an industry-unique DNS proxy model.

Being a DNS proxy (and along with web proxy in the SWG) means that all DNS traffic is inspected regardless of destination and traffic type. User endpoint traffic simply needs to pass through our proxy and then all DNS Control policy can be applied to all user traffic regardless of DNS resolver used.

Proxy advantage of DNS Control
The DNS proxy model is particularly effective when the end clients aren’t complying with corporate best practices for DNS resolutions. For example, if the corporate policy is to use Google’s DNS (8.8.8.8) or OpenDNS (208.67.222.222) or any public resolver but the endpoint goes somewhere else, then any non-proxy solution would miss these resolutions entirely. Perhaps the end client has malware that is trying to exfiltrate data via some uncontrolled DNS service or the user explicitly selected resolutions over HTTPS in their web browser (DNS over HTTPS) – either way, any DNS security based on the OpenDNS or Google DNS resolver would then be bypassed.

This weakness is not present when the Zscaler DNS proxy model is used. No other vendor currently provides a DNS security solution like DNS Control and using a DNS proxy.

Using a 3rd party public DNS resolver
In order to secure DNS and provide performant resolutions, the Zscaler Public Service Edge (PSE) needs to see the DNS traffic. If certain domains are excluded and resolved by a local DNS resolver (using Client Connector includes and excludes for example) then this traffic cannot be secured. If these are local domains used within the corporate network like “employeePC2.exampleCorp.com” or “InternalApp.exampleCorp.com” then the risk is low. All other traffic should pass through the PSE.

Zscaler has typically recommended that the customer point their client’s DNS resolutions to a public 3rd party DNS provider. Google’s is a good choice since they have a broad and publicly available network of resolvers – but any public DNS service will do.

Resolving DNS in the proxy
The DNS proxy model of DNS Control allows DNS to be intercepted and resolved as soon as the request reaches our Public Service Edge. This is configurable by endpoint and many other conditions in destination NAT policy and essentially amounts to two modes:

1. Transit Option: This passes DNS request through the proxy. Using a proxy means the customer IP address with be safely hidden from 3rd parties including the external resolver but DNS security policy will still be applied. This option is good for iterative requests which can’t be resolved by ZTR but can be secured by DNS Control.
2. Resolver Option: This mode will see and intercept the DNS request at the PSE and will resolve the request pending DNS Control policy. All security benefits are gained but also performance benefits of having DNS resolutions done quickly and with geographic context (user will get the closest Microsoft or AWS point of presence, for example).

Defining an explicit Zscaler DNS resolver
Despite have a Resolver Option (described above), some customers and prospects will insist on having an explicit resolver provided by Zscaler to which they can point their DNS requests. It may not matter to them that we would have intercepted queries to any/all 3rd party DNS resolvers and they might simply be used to legacy models where security was only able to be done by the DNS resolver – despite DNS Control security happening regardless of public resolver used.

Any of the Ghost IP addresses can be used as explicit DNS resolver IP addresses.

DNS queries using UDP:53 or TCP:53 to Ghost IPs are resolved by ZTR. These IPs are available in each data center accessed via the PSE and regular forwarding tunnel (GRE, IPsec, Client Connector, etc). The Ghost IPs are equivalent to anycast IP addresses used by competitive solutions but require the forwarding tunnel to be established in order to be accessible.

Find our more about Ghost IP via Zscaler Help.

Optionally the GRE VIPs can be used for UDP:53 and TCP:53 DNS requests. The only disadvantage of GRE VIPs is that they are specific to clouds and data centers. So if the user is mobile then their DNS requests will always resolve back to that data center in that geography – so response times might be slower and geographic context will only be from the DC’s geographic location. This is would not be an issue with customer network infrastructure like DNS forwarders or their data center applications since they are at fixed locations (and are never mobile) and so are good alternative solution to the Ghost IPs or when forwarding tunnels aren’t possible.

Defining an explicit Zscaler DNS resolver for tunnel-less connections
Sometime customers or prospects will require an explicit resolver but will not be able to push these requests via a normal Zscaler forwarding tunnel (like GRE, IPsec, or tunnels established by Zscaler Client Connector).

In these cases, the GRE VIPs of each data center and cloud need to be used as the explicit DNS resolver address. Even tunnel-less DNS requests to GRE VIPs will be answered by that data center’s ZTR cluster as long as a Location is configure in ZIA with the IP address of the DNS requestor.

This is a good solution for existing DNS infrastructure that won’t pass via the normal GRE (or other) forwarding mechanism because of network architecture or because the DNS infrastructure cannot easily be changed or when Client Connector isn’t an option (headless devices, wifi network APs etc). This is not a good solution for mobile endpoints like users and is mostly for DNS infrastructure like DNS forwarders that don’t move and have consistent IP addresses for the Location configuration.

[gjayaraman (Giriraj Jayaraman)]

Great article Stefan!

1. Zscaler DNS resolver would come into play only when the DNS queries are forwarded to our Public Service Edge. What is your recommendation for Private Service Edge /VSE customers?
2. Could you please explain the significance of zstrustedresolver.<cloud>.net in the NAT Control Policy with a use-case?

Thank you,
Giriraj

[Stefan_Sebastian]

1. DNS Control works similarly on private infrastructure like PrivSEs and VSEs (P/VZENs). The key difference is that DNS servers are specified by the customer (or sent to Google by default) in place of our ZTR.
2. ZTR in NAT control functions like a proxy behavior override. In a proxy model, when a customer’s client endpoints specify an address they want like the public DNS server 4.4.4.4. Unless a policy exists in NAT control (or any other aspect of the web or DNS proxy) then the proxy will try to oblige and direct traffic to that originally requested location. The first use case is to ensure that no DNS requests go anywhere else but some trusted DNS resolver (ours or a 3rd party). A NAT control rule will be specified to say any dest:53 from any internal users goes to 8.8.8.8. In this case, the 4.4.4.4 (and any other) DNS requests will be sent to 8.8.8.8 since that is the resolver the customer trusts. Alternatively, the customer admin trust our ZTR and simply enables the default rule which does the same thing but uses our ZTR instead of 8.8.8.8. Another popular use case is to bypass some internal DNS resolution from IP address 10.10.10.10 so these requests do not go to our ZTR or to 8.8.8.8. This is done when there is a special need like an iterative DNS server needing to go to root, then TLD etc (we support only recursive queries like everybody else) or there’s simply an exception like for some sort of testing. In this case, a higher ranking NAT control rule is specified that says any dest:53 from 10.10.10.10 or userXYZ goes to dest:53 (meaning transited through the proxy) is specified. See the Helpdocs for NAT Control for more information.

[Jamie_Brown]

Thanks Stefan for this great writeup - along with your other ones.

I tried configuring the ZIA Proxy IP as a DNS proxy and it worked well for DNS traffic from a known location with no tunnel - for allow traffic at least. A good reason to use this would be for DNS security for Guest networks, instead of the separate SHIFT service we’ve had to propose until now. The issue I ran into is that there is no block page like with SHIFT. I can’t even do a Block - Reset which would at least kill the session.

From what I can see, the way to provide a block page would be to Redirect the DNS response to some web server that would itself provide the notification. Am I on the right track here?

Cheers
Jamie

[Stefan_Sebastian]

yes, that’s right. Use the “redirect” action and that forges the A-record response with the IP address specified. That IP address needs to host the EUN page. We’ve experimented with using the Shift EUN page here and that might be a PS-led interim solution.

Longer term solution is to have an EUN page native to the DNS Control – particularly for these Shift replacement scenarios. We’re assembling the use cases now so it’s on the uncommitted roadmap at least.

This type of EUN only works if the DNS request results in web traffic of course. Until the DNS Control has an EUN and is co-deployed with the SWG, consider using the EUN in the proxy – so moving some of the use cases there. Any future DNS Control-based EUN will want to be integrated with the SWG proxy’s EUN when both exist.

Finally, we only support silent DNS blocks (drops, really) today. Don’t see why this would be a problem for just about all use cases but there some cases the client getting notified is desirable (and doesn’t retransmit requests etc). So also on the uncommitted roadmap is a block action that includes one or all protocol-based options for blocking DNS like NXDOMAIN, SERVFAIL, and/or REFUSED.

[Choon_Ping_Koay]

@Stefan_Sebastian

DNS Control works similarly on private infrastructure like PrivSEs and VSEs (P/VZENs).

Hi Stefa, you mentioned that “DNS Control works similarly on private infrastructure like PrivSEs and VSEs (P/VZENs)”, does it mean I can also can have P/VZENs VIP to be used as explicit DNS resolver IP addresses for DNS forwarder and on-prem users?