Skip to main content
Solved

How do I configure NPA to work with On-Premise DNSSEC

  • May 6, 2025
  • 4 replies
  • 136 views
Z

Looking for any information about how to best configure steering for private app access when DNSSEC is enabled on the on prem DNS servers, or if this is even possible. 

 

I have verified my NPA publisher is able to query DNS and get proper RSIG response. However remote clients do not get a valid response from the domain even with the Netskope suggested Active Directory configuration from: Netskope Private Access for Microsoft Active Directory Domain Services - Netskope Knowledge Portal

All nslookups come back as unsecured and Non-authoritative

Best answer by jneerdael

Netskope Clients use a concept of rewriting DNS records to a Stub IP (default in CGNAT range 100.64.0.0/10). The concept of intercepting and modifying DNS resource records in itself means Netskope Private Access does not support DNSSEC related resource records and does not have DNSSEC support enabled on the DNS resolver on Netskope Publishers. Hence DNS resource records as they arrive at a client will always be non-authorative since the Publisher has it’s own DNS resolver, and DNSSEC is not enabled and related DNS resource records are not tunneled to the endpoint.

S
C
Rohit_Bhaskar
This topic has been closed for replies.

4 replies

Z
  • zmcinroy
  • Author
  • May 7, 2025

I am seeing the following error when running nltest /dsgetdc:<mydomain>

Getting DC name failed: Status = 9505 0x2521 DNS_ERROR_UNSECURE_PACKET

The Active directory and DNS are setup according to netskope docs 

J
Netskope Employee
  • jneerdael
  • Netskope Employee
  • Answer
  • May 12, 2025

Netskope Clients use a concept of rewriting DNS records to a Stub IP (default in CGNAT range 100.64.0.0/10). The concept of intercepting and modifying DNS resource records in itself means Netskope Private Access does not support DNSSEC related resource records and does not have DNSSEC support enabled on the DNS resolver on Netskope Publishers. Hence DNS resource records as they arrive at a client will always be non-authorative since the Publisher has it’s own DNS resolver, and DNSSEC is not enabled and related DNS resource records are not tunneled to the endpoint.

Z
  • zmcinroy
  • Author
  • May 12, 2025

Netskope Clients use a concept of rewriting DNS records to a Stub IP (default in CGNAT range 100.64.0.0/10). The concept of intercepting and modifying DNS resource records in itself means Netskope Private Access does not support DNSSEC related resource records and does not have DNSSEC support enabled on the DNS resolver on Netskope Publishers. Hence DNS resource records as they arrive at a client will always be non-authorative since the Publisher has it’s own DNS resolver, and DNSSEC is not enabled and related DNS resource records are not tunneled to the endpoint.

Would this apply to DoH or DoT as well or would that traffic be tunneled to the endpoint without interruption? 

J
Netskope Employee
  • jneerdael
  • Netskope Employee
  • May 20, 2025

Would this apply to DoH or DoT as well or would that traffic be tunneled to the endpoint without interruption? 

This has not been validated, theoretically this might work but would require every app definition also to include the real app ip

Z

Badges Winner

Show all badges

Not finding what you're looking for?

Don't be shy and let us know about your challenge.

Ask your question here!
Terms & ConditionsCookie settingsAccessibility statement