Validate Wildcard Private App Segments

For wildcard Private App Segment definitions like *.acme.com, a stub IP (100.64.0.0/16) is returned for any hostname matching the SRP, regardless if there is a real DNS record on the other side of the Publisher.

When this Wildcard App Validation feature is enabled, the DNS request intercepted by the Netskope Client will be sent to the Publisher to determine if the domain resolves on the internal network. For a domain that can’t be resolved, the DNS request will be sent to the local network, thereby exempting the traffic from being steered by NPA. This could be very helpful for key use cases like App Segment Discovery, to not steer non-existent domains and for domains that are shared both internally as well as externally.

Use Case

• Private App Segment App Definition: *.acme.com
• Let’s assume there are three apps matching the definition: support.acme.com (not to be steered via NPA and also, unresolvable by the Publisher), jira.acme.com (to be steered via NPA), mytest.jira.acme.com (to be steered via NPA), and test.acme.com (non-existent domain).
• End-user attempts to access the above four apps.

The expected behavior is as follows:

Domain	Behavior
support.acme.com	The Netskope Client sends the DNS request to the Publisher for validation. The Publisher returns NXDOMAIN to the Client. The DNS request is then sent to the local network. Here, the key difference lies in the local DNS resolver successfully resolving the domain and directing the traffic either through SWG or directly to the destination.
jira.acme.com mytest.jira.acme.com	The Netskope Client sends the DNS request to Publisher for validation. As the resolution succeeds, the Client gets notified and a stub IP (100.64.0.0/16) is assigned and cached. Traffic flow will succeed via NPA.
test.acme.com	The Netskope Client sends the DNS request to the Publisher for validation. The Publisher returns NXDOMAIN to the Client. The DNS request is then sent to the local network.