ZPA DNS & App Discovery — Why "It Works by IP but Not by Name"

Sneha at Infosys reaches the HR app by IP (172.16.9.40) but hr.corp.local times out. The connector is healthy and the segment is published.

• The connector's /etc/resolv.conf points at a public/wrong DNS that can't resolve the internal zone
• The internal DNS record is missing or points to the wrong IP
• The app name only exists in a split-horizon internal view the connector isn't using

Resolve the app name on the connector, and compare the default resolver against the internal DNS directly.

cat /etc/resolv.conf
dig +short hr.corp.local
dig @10.10.0.53 +short hr.corp.local

nameserver 8.8.8.8            # public DNS — can't see corp.local
hr.corp.local: NXDOMAIN       # via default resolver
172.16.9.40                   # but the INTERNAL DNS knows it fine

Point the connector at the internal DNS server (10.10.0.53) that owns the corp.local zone, then restart the service.

echo "nameserver 10.10.0.53" | sudo tee /etc/resolv.conf
sudo systemctl restart zpa-connector

dig +short hr.corp.local via the default resolver now returns 172.16.9.40; users reach the app by name.

Users who type hr (the short hostname) get nothing, but hr.corp.local works. Some legacy bookmarks and scripts use the short form.

• The connector's /etc/resolv.conf has no search corp.local line to expand short names
• The App Segment lists only the FQDN, so the short name the user typed never matches a segment

Add a search domain so the connector expands short names, and define both name forms in the App Segment so either matches.

echo "search corp.local" | sudo tee -a /etc/resolv.conf
# then in the portal: add BOTH 'hr' and 'hr.corp.local' to the App Segment
sudo systemctl restart zpa-connector

getent hosts hr now returns 172.16.9.40; users reach the app whether they type the short name or the FQDN.

Rahul at TCS gets "app not reachable" for a newly-stood-up app. The connector is green; the segment is correct. From the connector, the name returns NXDOMAIN even against internal DNS.

The A record for the app simply doesn't exist in the internal zone yet (new app), or it was created in the wrong zone/view. ZPA can't broker to an IP the connector can't learn.

Create the A record in the internal zone that the connector queries (or correct the zone/view). This is a DNS-team fix, not a ZPA one — but you prove it from the connector.

dig @10.10.0.53 +short newapp.corp.local returns the correct IP; the brokered session now reaches the app.

Everything worked, then someone added a *.corp.local App Segment for convenience — and now one specific app (hr.corp.local) behaves differently or routes to the wrong location.

The wildcard now claims names that previously had no segment — and if it maps to a different connector/server group than the app's location, traffic is brokered through the wrong place. Worse, if there's no more-specific FQDN segment, the wildcard's group wins by default.

In the portal, list segments that overlap the name and see which group each maps to. Use ZPA Diagnostics to confirm which segment/connector served the FQDN.

# Segment 1: *.corp.local   -> Connector Group A (DC-Pune)
# Segment 2: (none specific for hr.corp.local)
# ZPA Diagnostics: hr.corp.local served by Group A  # wrong DC

hr.corp.local matched: *.corp.local (wildcard)
served by: Connector Group A (DC-Pune)   # app actually lives in DC-Mumbai

Add a more-specific FQDN segment for hr.corp.local mapped to the correct connector group — the specific segment then wins over the wildcard automatically.

ZPA Diagnostics shows hr.corp.local now served by the correct group; the app behaves exactly as before the wildcard was added.

After a broad wildcard segment is published, some traffic that should go out through ZIA (or directly to the internet) starts trying to route via ZPA — users report certain SaaS or internet hostnames suddenly failing or slowing.

A wildcard like *.com or an over-broad internal pattern matches far more names than intended. ZPA claims them, but the connector can't (and shouldn't) resolve or reach public destinations — so those sessions die in ZPA instead of going to ZIA.

Identify which names the wildcard captures, and confirm with ZPA Diagnostics that an internet hostname is being matched by a ZPA segment.

# ZPA Diagnostics on a failing SaaS host:
# saas-tool.example.com matched: *.example.com (ZPA wildcard)
# expected lane: ZIA / direct internet — NOT ZPA

matched segment: *.example.com  (ZPA)
result: no app / unreachable     # ZPA can't serve a public SaaS host

Tighten the wildcard to the internal namespace only (e.g. *.corp.local, not *.com), and add specific FQDN segments for the handful of internal apps that need ZPA. Let everything else fall through to ZIA.

ZPA Diagnostics shows the internet hostnames no longer match any ZPA segment; they route via ZIA/direct again and recover.

An app in DC-Mumbai is suddenly slow or unreachable. The app, DNS, and connectors all look fine — but the FQDN is being brokered through a connector group in a different region.

A wildcard segment mapped to the wrong connector/server group claims the name. Without a more-specific FQDN segment pointing at the right group, the wildcard's group wins — even though it can't optimally (or at all) reach the app's subnet.

Create a specific FQDN segment for the app, mapped to the connector group that actually sits next to it. Precedence does the rest — the specific segment wins and the path straightens out.

ZPA Diagnostics shows the app served by the local group; latency drops and reachability is restored.

Priya at Wipro can resolve and reach an internal app, but it rejects her — or logs the wrong source. The app's allow-list / licence is keyed to the user's office IP range, and after moving to ZPA every session looks like it comes from one IP.

In ZTNA the connector terminates the user session and opens a fresh one to the app — so the app sees the connector's source IP (e.g. 10.20.5.11), not the user's. Any ACL, geo-rule, or licence keyed to the user's IP now fails or mis-attributes.

Check what source IP the app server actually logs for a ZPA session, and compare it to the connector's IP.

# app access log for a ZPA-brokered request:
tail -f /var/log/app/access.log
ip addr show   # on the connector — note its source IP

access.log: 10.20.5.11 - - "GET /hr" 403 (ACL: src not allowed)
# 10.20.5.11 = the App Connector, NOT the user's 192.0.2.x office IP

Two options: (1) allowlist the connector's subnet on the app/ACL (simplest, but loses per-user IP granularity), or (2) use Source IP Anchoring (SIPA) so the app sees a controlled, known source IP. Note: pure ZTNA can't preserve each user's original client IP — anchoring gives you a predictable one instead.

The app's access log shows the expected anchored/allowlisted source IP, the 403s stop, and IP-keyed licensing counts sessions correctly.

A vendor app counts "concurrent IPs" for licensing, or applies a geo/IP rule. Under ZPA it either over-counts (everyone shares the connector IP looks like one user) or blocks users because the connector's IP isn't in the licensed range.

The app's logic assumes the source IP identifies the user or their location. Behind ZPA, the source is always the connector — so per-user IP assumptions collapse.

Allowlist the connector subnet in the app's licensed range so the connector IP is accepted, and move seat-counting to a user identity signal (ZPA passes the authenticated user), not source IP. Use Source IP Anchoring where the vendor must see a specific public egress IP.

Licensed users are admitted, seat counts track real users (by identity), and the geo/IP rule passes for the anchored source.

You open the discovered-applications view expecting to see what users access — and it's empty. Users are reaching apps successfully, so the connectors clearly work.

• Application discovery is simply not enabled in the tenant
• There's no wildcard discovery segment for the connector to observe traffic against
• Discovery is on, but users aren't yet sending traffic through the relevant segment

In the portal, confirm discovery is enabled and that a wildcard segment exists for the namespace you expect to discover.

# 1. Application discovery feature: ENABLED?
# 2. Wildcard discovery segment e.g. *.corp.local : exists + access policy?
# 3. Are users actually sending traffic to *.corp.local names yet?

discovery: OFF
wildcard discovery segment: none
=> discovered-apps list will stay empty by design

Enable application discovery, create a wildcard discovery segment (e.g. *.corp.local) with an access policy for the target users, then let real traffic flow. ZPA observes the interactions and populates the list.

After real user traffic flows for a while, the discovered-apps list begins to populate with the FQDNs/IPs users actually hit.

Discovery is enabled and a *.corp.local wildcard segment exists, but nothing shows up. The team suspects a bug.

Discovery is traffic-driven: it learns apps by watching real user sessions. If users haven't been assigned to the discovery segment, or simply haven't accessed anything under it yet, there's nothing to learn. An empty list is the expected state, not a fault.

Confirm the access policy lets the right users reach the discovery segment, then drive a representative set of users to actually use their apps. Give it time — discovery accumulates as traffic flows.

As sessions to *.corp.local names appear in the logs, matching apps begin showing in the discovered-apps list.

Discovery is working and the list is full — but everything is still being served by the broad wildcard, so you have no per-app policy, logging, or precedence control.

A wildcard discovery segment is meant to be a starting point. Leaving every app on the wildcard gives you no granularity — and no way to route a specific app to the right connector group (precedence only kicks in once a specific segment exists).

For each identified app, create a defined (specific) FQDN segment mapped to the correct connector group, with its own access policy. The specific segment wins over the wildcard by precedence; engage app owners to classify the ambiguous ones.

ZPA Diagnostics shows each promoted app served by its specific segment/group; per-app policy and logging now work, and the wildcard only catches the long tail.

A subset of clients or services need to query the internal DNS server itself over ZPA, but they can't — name resolution that depends on reaching 10.10.0.53 fails for those flows.

The internal DNS server is just another private resource — if there's no App Segment that brokers traffic to it (TCP/UDP 53 to 10.10.0.53), ZPA won't carry those queries. Don't confuse this with the connector's own resolution, which uses the host's /etc/resolv.conf directly.

Create an App Segment for the internal DNS server (its IP or FQDN, ports TCP/UDP 53), mapped to a connector group that sits next to it, with an access policy for the clients that need it.

The dependent clients can resolve names that require the internal DNS server over ZPA; the brokered DNS flow shows up in the logs against the new segment.