The concept of a resolver in AppGate ZTNA is a loose term covering the mechanisms used by AppGate ZTNA to resolve a range of different types of host definitions. These different mechanisms are invoked according to the syntax used to define the host(s) in the entitlement action.
In the remainder of this topic we are looking at hosts defined using dns://myserver1.myco.com which will always use the DNS resolver, and domain://myserver1.myco.com which will always use the DNS forwarder. In both cases the appliance's hosts file will be checked first, if enabled in Sites, before any external DNS requests are made.
The DNS resolver works in parallel with the Device DNS used by the Client; the DNS forwarder effectively works in series, providing answers to any device DNS requests.
Fast changing IP addresses
The system is designed to respond to changes in resolved names, such as when an autoscaled instance is added. However, it is not designed to handle large numbers of frequently changing resolved names. Gateways run a dynamic queuing system to handle such changes on a per-user basis. If the system has 500 users of which all have 20 actions that change, then the queue is immediately 10,000 in size. Larger Gateways will have larger queues and faster Gateways will process the queue in less time, but care still needs to be taken to ensure that host definitions resolve to consistent values appropriate for your use case.
There is a warning mechanism built into the DNS resolver which will trigger when inconsistent DNS values are being received by the AppGate ZTNA system. Once there are more than ten results, the number of changes over a given time frame is divided by the number of results to give an instability score. Over a certain threshold a warning will appear in the dashboard:
Accessing SaaS providers
If you plan to use AppGate ZTNA to control access to SaaS providers, then you need to use the DNS forwarder. Most SaaS providers use global DNS LB to answer to DNS requests, and the DNS responses can list many IP addresses (i.e. https://ip-ranges.amazonaws.com/ip-ranges.JSON) that can change frequently. Each time the DNS record expires (typical TTL between 1 and 5 min), the new list is retrieved and the Gateway will update the firewall rules and the client routes if there have been changes.
This can lead to two problems:
If a DNS resolver is used (even to the same DNS server as the Gateway uses), DNS may be queried at different times by the client and the DNS resolver, so each can end up with a different set of results.
The client may use a local ISP's DNS server (because this is a public URL), but because it is in a different region to the Gateways, it might be given a different set of results.
The user's device DNS and Gateway DNS need to remain in sync for reliable operation. This is a clear case in which the DNS forwarder should be used.
DNS resolver
Use the Sites UI to configure a DNS resolver
The user's device and Gateway operate independently and live in different network environments, with each making DNS requests independently.
At sign-in
The client uses the user's DNS policy to set the device's DNS (based on Match Domains and internal DNS Servers).
When no DNS policy is specified, the IdP's DNS settings will be used.
In Sites, the DNS resolver(s) that should be used by the Gateways is specified.
The user's access policy defines the entitlements allowed (which include all the host definitions); the Gateway uses the Go name daemon to resolve these hostnames based on Match Domains and DNS Servers. The results are obtained from the hosts file, Go name daemon's DNS cache, or using a fresh DNS request.
Thereafter, this is refreshed at the Update Interval for the Site (default 60 seconds).
The Go name daemon updates the session daemon.
The session daemon updates the VPN daemon for firewall rules.
The session daemon sends the client the required routes.
The client writes host routes to the device.
At use time
The user accesses an application, triggering a DNS request.
The client captures the DNS request (based on match domain) and routes this via the appropriate Gateway to the DNS server.
The DNS response is sent to the user's application.
Application traffic is routed through the clients tunnels via the appropriate Gateway to the (protected) host.
From the above, you see that the two DNS requests cycles are triggered at different times, possibly with different TTLs. Initially, the Gateway looks up the allowed (protected) hosts defined in entitlements, and later the device looks up the specific protect host they are using. Even when the same DNS server is specified, this can lead to some inconsistencies when resolved IP addresses have short TTLs. This model is best used with relatively static DNS records.
DNS forwarder
Use the Sites UI to configure a DNS forwarder
The DNS forwarder supports hostname resolution (domain://crm.internal.my_company.com) as well as sub-domain resolution (domain://internal.my_company.com).
Even though the client and Gateway remain independent, in this case the Gateway handles DNS requests on behalf of the client.
At sign-in
The client uses the user's DNS policy configuration based on Match Domains and DNS Servers to set the device's DNS to point towards the DNS forwarder's CoreDNS instance.
The Site settings define that DNS forwarding should be used on the Gateways. Both Match Domains and DNS Servers can be specified for one or more internal DNS servers.
At use time
The user triggers a DNS request.
The client captures the DNS request (based on match domain) and routes this to the Gateway's DNS forwarder on 100.127.x.y.
The Gateway uses the DNS forwarder to resolve hostnames based on Match Domains and DNS Servers. The results are obtained from the hosts file, the DNS cache, or using a fresh DNS request.
This is repeated for each user request.
If the DNS result includes a TTL, this is honored and the result is cached for this time.
If the DNS result does not include a TTL, then the Default TTL for DNS lookups for the Site is used (default 300 seconds).
The DNS forwarder updates Sessiond.
The session daemon checks the entitlements are allowed.
Sessiond updates VPNd for firewall rules.
Sessiond sends the client the required routes.
The DNS forwarder sends the DNS response to the user's application.
Application traffic is routed through the client's tunnels to the protected host via the appropriate Gateway firewall rule.
Client DNS auto-configuration will set DNS up in two different places in the AppGate ZTNA system: once for the user's device and again for the Gateway. But instead of these being parallel configurations, they can now be considered to be in a series with each other, so the DNS behavior is now unified. Every DNS request sent via the client triggers the DNS forwarder, which will provide a single response shared between the application requesting access and the Gateway's firewall engine.
Accessing SaaS providers
If you plan to use AppGate ZTNA to control access to certain SaaS providers, then this approach ensures the application (browser) and Gateway DNS results are unified, ensuring reliable operation.
Another problem with some SaaS providers is that the content can load from numerous URLs, which in a solution like AppGate ZTNA would all need to be given access. Another benefit of the DNS forwarder is that it will also resolve (sub)domains. So if the entitlement contained domain://my_co.com, then myserver1.my_co.com would be resolved and allowed. This approach makes it easy to set up SaaS.