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 (184.108.40.206) or OpenDNS (220.127.116.11) 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:
- 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.
- 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 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. 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.