Access Private App Segments using PQDN

When migrating to ZTNA-based solutions, you may want to retain the same user experience for your users. One of the frequent requirements is the ability to support application access by PQDN (a short name). For example, instead of app1.example.com, a user could type app1 in the browser.

When the Multi Search Domains Support feature is enabled, the Netskope Client will support access using PQDNs. The Netskope Client will be able to iterate (top-down) through the multiple search domains and validate domains after appending search domains.

How does the Multi Search Domains Feature Work?

• There is no additional configuration required in the web UI for this to work.
• The Netskope Client intercepts and validates domain resolution by tunneling DNS requests (iterating through the list) to the Publisher for individual Search Domains.
• Assign stub IP (100.64.0.0/16) only if a domain match in the SRP is resolvable on the Publisher.
• If the Publisher returns NXDOMAIN, the DNS request is sent back to the local network.
• Valid (stub IP – 100.64.0.0/16) responses are cached by the Client.
• Publisher DNS validation remains effective, assigning a real IP if the domain is resolvable on the Publisher.

Important Considerations

• It is expected that the Wildcard App Validation feature is turned on for this feature to work. This feature gets automatically enabled along with the Multi Search Domain Support feature; however, if the Wildcard App Validation feature is explicitly disabled, Multi Search Domain Support will stop working.
• It is expected that the DNS server configuration and resolution is identical for Publishers assigned to an app.
• In case of multiple valid search domain matches, only the first top-down valid domain will work.
• The Admin should manage and control search domains, not the Netskope Client.
• If the user entered domain (PQDN or FQDN) matches a wildcard app definition in the SRP, the Netskope Client sends the DNS request to the Publisher to determine if the domain is resolvable. The behavior of FQDN with this feature is explained in Scenarios 2 and 3 below. Essentially, when Multi Search Domains Support is enabled, FQDN access would continue to work.

Use Cases

Scenario 1

• Private App Segment definition: *.acme.com (wildcard app definition).
• The DNS search domains configured on the network adapter (in order): *.acme.com, *.acme.local, *.eu.acme.com
• End user types jira (PQDN) in a browser to access the app. The domain which end user intends to connect to is jira.eu.acme.com

The expected behavior is as follows:

Step	Description
1	The Netskope Client learns all search domains configured on the network adapter.
2	The Netskope Client appends suffix domains from top to bottom and tunnels DNS requests to the Publisher for validation.
3	The First DNS request matching SRP is jira.acme.com. The Publisher returns NXDOMAIN to the Client.
4	The next suffix domain *.acme.local does not match SRP and hence, iterates to the next domain.
5	The Client attempts the next suffix domain *.eu.acme.com (SRP match) and tunnels the DNS request to the Publisher.
6	After the resolution for jira.eu.acme.com succeeds on the Publisher, the Client gets notified, learns the position of the valid search domain, and a stub IP is assigned and cached. The app access succeeds.

Scenario 2

• Private App Segment definition: *.acme.com (wildcard app definition).
• The DNS search domains configured on the network adapter (in order): *.acme.com, *.acme.local, *.eu.acme.com
• End user types jira.eu.acme.com (FQDN) in a browser to access the app.

The expected behavior is as follows:

Step	Description
1	The Netskope Client learns all search domains configured on the network adapter.
2	The Netskope Client appends suffix domains from top to bottom and tunnels DNS requests to the Publisher for validation.
3	When the app definition matching request is a wildcard (in this case, *.acme.com) and this feature is enabled, the first DNS request sent to the Publisher is for jira.acme.com and not jira.eu.acme.com. The Publisher returns NXDOMAIN for jira.acme.com to the Client.
4	The next suffix domain *.acme.local does not match SRP and hence, iterates to the next domain.
5	The Client attempts the next suffix domain *.eu.acme.com (SRP match) and tunnels the DNS request for jira.eu.acme.com to the Publisher.
6	After the resolution for jira.eu.acme.com succeeds on the Publisher, the Client gets notified, learns the position of the valid search domain in the list and a stub IP is assigned and cached. The app access succeeds.

Scenario 3

• Private App Segment definition: jire.eu.acme.com (FQDN app definition).
• The DNS search domains configured on the network adapter (in order): *.acme.com, *.acme.local, *.eu.acme.com
• End user types jira.eu.acme.com (FQDN) in a browser to access the app.

The expected behavior is as follows:

Step	Description
1	The user entered FQDN is an exact match with the app definition, so no further validation is required. This also means that no DNS requests are forwarded to the Publisher.
2	The Netskope Client assigns a stub IP for jira.eu.acme.com and gets cached. The app access succeeds.