DNS suffixes to resolve FQDNs to IP addresses
DNS suffix is a global configuration that is applied for all end users. The DNS suffix feature of the Citrix Secure Private Access service can be used for the following use cases:
- Enable the Citrix Secure Access client to resolve a non-fully qualified domain name (host name) to a fully qualified domain name (FQDN) by adding the DNS suffix domain for the back-end servers.
- Enable admins to configure applications using IP addresses (IP CIDR/IP range), so that the end users can access the applications using the corresponding FQDN under the DNS suffix domain.
For example, while resolving a non-fully qualified domain name “workday”, if the DNS suffix “citrix.net” is configured, the operating system appends the suffix “citrix.net” and resolves to “workday.citrix.net”.
If multiple DNS suffixes are configured, the DNS suffixes are resolved in a sequence. For example, assume that the following suffixes are added:
".citrix.net"
".citrix.com"
".xenserver.com"
When an end user types “workday”, the operating system attempts to resolve the FQDNs in the following sequence. If it succeeds with one suffix, the remaining suffixes are skipped.
- workday.citrix.net
- workday.citrix.com
- workday.xenserver.com
Important:
DNS suffix configuration can only enable the client to resolve a non-fully qualified domain name by suffixing the domain configured using the DNS suffix feature. For an end user to access an FQDN under the DNS suffix domain, the admin must configure an application with an IP address, FQDN, or a wildcard domain. For details, see point 4 in Use case example.
If two different applications are configured, one with FQDN and another with IP address, both corresponding to the same back-end server), then the policy of the application with IP address takes higher precedence. For details, see point 5 in Use case example.
Prerequisites
- Customers must be entitled to the Secure Private Access Advanced edition to use the DNS Suffix feature.
- Contact the Citrix Product Management team to get the DNS suffix feature flags enabled.
How to add DNS suffixes
-
On the Secure Private Access tile, click Manage.
-
On the Secure Private Access landing page, click Settings, and then click DNS suffix.
-
In the DNS Suffix field, enter the suffix that must be appended when resolving a non-fully qualified name.
-
Click Add.
The suffixes are listed based on the order that they are added. Admins can delete or modify the suffixes.
Example use case
Consider the following:
- An admin has assigned the IP address 192.0.2.1 to a machine in the customer network.
- The FQDNs for the machine (with IP addresses 192.0.2.1) are under the domain “citrix.net” (example, workday.citrix.net).
DNS suffix and app configuration | End-user experience | ||
---|---|---|---|
1 | Admin configures the DNS suffix as “citrix.net” and creates an app with IP address 192.0.2.1 with an access policy set to “allow” for user1. | When user1 tries to connect to “workday”, the FQDN is suffixed with “citrix.net,” (workday.citrix.net) and the IP address is resolved to 192.0.2.1. Because 192.0.2.1 is allowed for user1 with an app configured, access is granted. | |
Note: End user can access the Workday app with 192.0.2.1 or workday.citrix.net or “workday”. | |||
Without DNS Suffix configuration, access through “workday” and “workday.citrix.net” are denied. | |||
2 | Admin configures the DNS suffix as “citrix.net”, creates an app with FQDN (workday.citrix.net), and sets the access policy to “allow” for user1. | When user1 tries to connect to “workday”, “citrix.net” is suffixed to “workday” (workday.citrix.net). End user can access Workday because an application is configured with “workday.citrix.net” and the access policy is set to “allow” for user1. | |
Note: End user can access the Workday app with workday.citrix.net or “workday.” | |||
Access to 192.0.2.1 is denied as there is no app configured with this IP address. | |||
3 | Admin configures the DNS suffix as “citrix.net”, creates an app with wildcard domain “*.citrix.net,” and sets the access policy to “allow” for user1. | When user1 tries to connect to “workday”, “citrix.net” is suffixed to “workday” (workday.citrix.net). End user can access Workday because an application is configured with “*.citrix.net” and the access policy is set to “allow” for user1. | |
Note: End user can access Workday with workday.citrix.net or “workday”. | |||
Access to 192.0.2.1 is denied as there is no app configured with this IP address. | |||
4 | Admin configures the DNS suffix as “citrix.net.” No application is configured for user1 with FQDN (workday.citrix.net) or 192.0.2.1. | When user1 tries to connect to “workday”, “workday” is suffixed with “citrix.net” by the client and resolves “workday.citrix.net” to 192.0.2.1. However, user1 cannot connect to the private server (workday.citrix.net/192.0.2.1) because there is no app configured with 192.0.2.1 or workday.citrix.net or *. citrix.net for user1. | |
5 | Admin configures DNS Suffix as “citrix.net.” Adds an app with IP address 192.0.2.1, and sets the access policy to “deny” for user1. Then adds another app with FQDN (workday.citrix.net) that resolves to 192.0.2.1 and sets the access policy to “allow” for user1. | When user1 tries to connect to “workday”, “citrix.net” is suffixed to Workday (workday.citrix.net) and the IP address is resolved to 192.0.2.1. However, access to Workday is denied as the policy of the application configured with IP 192.0.2.1 takes precedence over the app configured with FQDN. |