DNS configuration in the AppGate ZTNA system can be done in two ways, both aimed at providing consistency in DNS behaviors across different operating systems. They use specialized configuration options, driven by special syntax that overcomes the limitations outlined above, providing the optimal match-domain model for DNS requests.
Unless you are using the client DNS auto-configuration option, you need to add an entitlement so the user's application is able to access the DNS server(s) you have specified. Leave access control set to Always Allow Action(s).
Using DNS auto-configuration (Preferred)
The client DNS auto-configuration simplifies DNS configuration in that users are no longer required to manually create the DNS policy and an entitlement to associate with that policy and any related groups.
Use the Sites UI to configure DNS using auto-configuration.
The client DNS auto-configuration feature uses your resolver's DNS settings for clients when no other DNS policy exists. To do this, when configuring a DNS resolver for the Site, you define the DNS server and the match domain. Then you select Enable auto-configuration under Client DNS to ensure the client is configured in the same way as the Gateway. A DNS policy will then be automatically created along with a suitable entitlement.
This will be assigned automatically when a user has at least one other entitlement for this Site and no other DNS policy assigned.
Using DNS Policy (Advanced)
When DNS configuration is set using a DNS policy, it makes it possible to configure multiple different DNS user groups within one system based on criteria such as IdP or geolocation of the user.
Use the Policies UI to add a DNS configuration.
You do not need to consider special syntax when using a DNS policy as the only option is when the use of a default domain is required.
The affinity that links a specific DNS server to a DNS domain is generated from the list in the DNS policy. This will generate as many affinity pairs as required which can be specified in any order:
10.11.12.13 <> foo.com
- this setting will use 10.11.12.13 but only for DNS requests ending in foo.com.
The most specific domain will always have the highest priority:
10.11.12.13 <> foo.com
10.11.12.113 <> bar.foo.com
- this setting will use 10.11.12.113 for DNS requests ending in bar.foo.com and 10.11.12.13 for DNS requests ending in notbar.foo.com.
After all match domains are dealt with, the system DNS (default) will be used to resolve all other DNS requests.
Default domain syntax
Mobile clients use the built-in VPN implementation of the mobile operating system. These require a default DNS server to be configured for the system to use. For iOS, IPadOS, Android, and Chrome you must include a default domain or no DNS settings will be applied. (For example, you could set the default domain to 8.8.8.8 and have a match domain to an internal server such as 172.10.1.20.)
Portal and lite clients operate in a less advanced environment than the normal client but still require a DNS server configured to work. For this type of client you must include a default domain or no DNS settings will be applied.
Desktop clients may be required to overrule the system DNS and send all DNS requests through AppGate ZTNA, possibly to a secure internal DNS server. Therefore, you can include a default domain for desktop operating systems.
To specify a default domain, enter default into the Match Domain field and add one or more IP addresses into the DNS Servers field:
10.11.12.13 <> default
- this will force all DNS requests to use 10.11.12.13
It is possible to combine the default domain with specific domains:
10.11.12.13 <> default
10.11.12.113 <> bar.foo.com
10.11.12.113 will be used for DNS requests ending in bar.foo.com and 10.11.12.13 for all other DNS requests.
Within IdP configuration (Deprecated)
NOTE
To migrate your settings from your IdP configuration, see the Migrating DNS settings section.
When DNS configuration is done within the identity provider, it is possible to configure DNS differently for divergent user groups (tenants) within one system.
Use the Identity Providers UI to add a DNS configuration.
You may or may not need to use this special syntax depending the native behavior of the device operating systems and your actual requirements.
This syntax is NOT supported for Portal clients that only ONLY use the DNS Servers configuration (and ignore the DNS Domains configuration).
When entering multiple DNS Domains they can be specified in any order.
The DNS domain syntax follows the format:
dns.server.<IP address>.<domain>.<action> The <action> being optional.
All operating systems
To improve affinity, the special syntax can be used to link a specific DNS server IP address to a DNS domain:
dns.server.10.11.12.13.foo.com
- this setting will use 10.11.12.13 but only for DNS requests ending in foo.com.
It is possible to specify multiple domains using the special syntax, in which case the most specific domain will always have the highest priority:
dns.server.10.11.12.13.foo.com
dns.server.10.11.12.113.bar.foo.com
- this setting will use 10.11.12.113 for DNS requests ending in bar.foo.com and 10.11.12.13 for DNS requests ending in notbar.foo.com.
Windows and Linux
The DNS servers setting will be tried to resolve all other DNS requests not specified in DNS Domains since AppGate ZTNA has the highest priority.
macOS
macOS has native affinity, but the DNS Servers setting can be used in conjunction with additional DNS Domains that use the special syntax:
foo.com
dns.server.10.11.12.113.bar.foo.com
- this setting will use 10.11.12.113 for DNS requests ending in bar.foo.com and the specified DNS server for DNS requests ending in notbar.foo.com.
The system DNS will be used to resolve all other DNS requests not specified in DNS Domains. That said, there may be occasions where you would like to overrule the system DNS and send all the DNS requests through AppGate ZTNA, for instance to some secure internal DNS server. To do this, the <action> option can be used on the end of the special syntax. If the <action> specified is default the specified IP address is used as the default DNS server:
dns.server.10.11.12.13.default
- this will force all DNS requests to use 10.11.12.13
Again, it is possible to combine this special syntax with the normal format macOS uses, such as:
dns.server.10.11.12.13.default
bar.foo.com
- the DNS server configuration will be used for DNS requests ending in bar.foo.com and 10.11.12.13 for all other DNS requests.
Improving look up times
To improve look up times, the <action> option can be used on the end of the special syntax. If the <action> specified is nxdomain it just returns NXDOMAIN:
dns.server.1.2.3.4.foobar.com.nxdomain
- this setting means the driver will never send the DNS request to 1.2.3.4 for foobar.com but instead it returns NXDOMAIN.
NOTE
The fact that the request is never sent means the <IP address> could be fake or real.
The use of this special syntax will teach Windows to use lower priority DNS servers for requests for foobar.com and not to waste time trying the DNS Server configured in AppGate ZTNA.
The <domain> can be left out of the special syntax:
dns.server.1.2.3.4.nxdomain
- this setting means the driver will return NXDOMAIN for all domains (which on its own is not very useful).
This option can be combined with the syntax explained earlier:
dns.server.10.11.12.13.foo.com
dns.server.10.11.12.113.bar.foo.com
dns.server.1.2.3.4.nxdomain
- this setting means the driver will immediately return NXDOMAIN for all domains that have not already been matched with any earlier domain matches for foo.com and bar.foo.com
The use of this special syntax will teach Windows to use lower priority DNS servers for all requests apart from those explicitly specified, avoiding the wait time for a reply.