Customer's internal domain is .net. An identical domain exists on the internet. Interaction between NPA and DNS Security

Oh man, what a mess.

Best bet in the short term is probably to create an internal zone of that domain which blackholes that domain.

Long term, they should consider not using a domain which they do not own internally.

The Core Problem
When Netskope NPA is configured to steer customer.net, the client intercepts all DNS queries for that domain and routes them through the tunnel to the publisher. The client has no way to distinguish "internal customer.net" from "public customer.net" at the steering level — they look identical.
The DNS Solution — Split-Horizon
Configure your internal DNS server (the one the publisher resolves against) to be authoritative for customer.net and contain only your internal host records.
How it works with NPA:
- DNS query for internalapp.customer.net → goes through publisher → internal DNS → resolves to private IP → NPA routes it correctly
- DNS query for publicsite.customer.net → goes through publisher → internal DNS → NXDOMAIN (no record) → connection fails through NPA
This is effective but has one significant caveat: users cannot reach public customer.net resources while NPA is active because internal DNS has no record for them. You would need to handle that separately (see below).
For this to work you must also enable "Use Publisher DNS" on the NPA private app definition. Without that, the client may fall back to external DNS and resolve the public domain regardless.
Complementary NPA Configuration
Split-horizon DNS alone solves the resolution problem but leaves a gap if users legitimately need to reach the public customer.net. Combine it with:
1. Specific hostnames instead of wildcards
Rather than steering *.customer.net or customer.net broadly, define the NPA private app with only the specific internal FQDNs you own:
internalapp.customer.net
db.customer.net
api.customer.net
Public customer.net hostnames that aren't in the NPA app definition won't be intercepted at all and will resolve normally via external DNS.
2. Bypass URIs for known public hostnames
If you know the specific public customer.net hostnames users need to reach, add them as bypass entries in the NPA app or steering configuration. Those specific FQDNs will skip NPA entirely and go direct to the internet.
Recommended Combined Approach
Layer    Configuration
Internal DNS    Authoritative zone for customer.net, internal records only
NPA App definition    Specific internal FQDNs only, not *.customer.net wildcard
NPA App setting    Use Publisher DNS: enabled
NPA Bypass    Add any known public customer.net hostnames users need
The specific hostname approach in the NPA app definition is the most important control — it prevents NPA from intercepting traffic you never intended to steer. Split-horizon DNS is the safety net that catches anything that slips through the domain match. Together they ensure internal customer.net goes through NPA and public customer.net does not.