DNS on the user's device can be hard to configure. This is due to different operating systems, and that Clients use different, local DNS servers located remotely from the internal DNS servers you need them to use.
Resolving appliance hostnames
Controllers and Gateways need public DNS records. To create predictable behavior, the driver will cache the DNS responses it gets for both Controllers and Gateways before it establishes the secure tunnel connection to the Gateways. Once the tunneled connection is established, these cached responses will be used instead of any new (internal) DNS server that may have been configured by the Entitlements. This avoids issues related to the Client seeing DNS responses from the internal domain and then not being able to perform token renewal because that IP address is not currently accessible. When the device roams to a different network, the Client reconnects, the cache gets cleared, and the caching process starts over again.
Resolving (protected) hosts
Protected hosts frequently sit within a few internal domains, so using match-domain would be the optimal way to configure the operating system's DNS for resolving hosts defined in Entitlement Actions. However, there are two problems that need to be overcome first:
Generic DNS configuration options across different operating systems do not necessarily support this.
DNS behaviors may not be consistent across different operating systems.
There is a less well known mechanism in Windows called Name Resolution Policy table (NRPT). This is used by AppGate ZTNA when a DNS Policy is used (recommended). The NRPT contains rules that specify DNS settings for given names or namespaces. When Windows performs DNS name resolution, it always checks the NRPT first for a match, and only sends a DNS request to any configured DNS servers on a no-match.
Windows tries any configured DNS servers sequentially according to the network priority set; when no DNS record is returned, then Windows tries the next DNS servers with a lower priority until it gets a reply. When the AppGate ZTNA IdP is used this sets specific DNS Server(s) which will be given the highest priority, so it will always receive all DNS requests. When you also set a DNS domain name in the AppGate ZTNA IdP (not recommended), this adds one or more search domains (i.e. here.mycompany.com) to any DNS search requests. This is done to support Windows' use of shortnames, which would result in a DNS request for youtrack.here.mycompany.com for the shortname youtrack. This means there is no affinity between the DNS domain names configured and the DNS servers configured. If you had two internal domains with independent DNS Servers and you wanted to avoid waiting for DNS timeouts, then all DNS requests for both domains would need to be handled by both internal DNS servers.
Normally, macOS and Linux use a form of limited affinity, which is better aligned with the way AppGate ZTNA works. For a given NIC, DNS domains are matched to the DNS server configured; then all other DNS requests are sent to the DNS server configured for the local network. This means you must configure both the DNS Servers and Match Domains or DNS requests will only be sent to the DNS server on the local network. This approach works for a relationship in which all configured domains will use the DNS server(s) configured, but does not support two internal domains with independent DNS servers. Also, unlike Windows, there is no easy way for all DNS requests to be sent to any server other than the DNS server on the local network.
Due to the use of advanced DNS configurations used for these operating systems, checking the device's DNS settings and the device's resolution of specific hostnames needs to be done in specific ways. If you think DNS is causing connectivity problems, refer to Troubleshooting user/device access.
Private DNS
Browsers and operating systems are also introducing another hurdle in the form of Private DNS, also known as DNS over HTTPS (DoH). DoH sends DNS requests through an encrypted connection, making it harder for others to see which websites are being accessed.
The browsers and operating systems in question often have limited forms of DoH back-off when local DNS providers are configured or if a VPN is in use. These then take precedence over sending requests via the configured DoH provider. However, browsers and operating systems operate differently from one another and users may have configured the back-off options differently, so there is no guarantee that the configurations set by AppGate ZTNA will work. Often the DoH settings will override all other settings, so the DoH function may need to be limited or disabled for AppGate ZTNA to work correctly. Check the documentation for the the specific combination of browser and operating system and adjust the settings appropriately.