NPA and DNS resolution issues

  • 14 September 2023
  • 7 replies
  • 903 views
J
Userlevel 2
Badge +5
Netskope is not compatible with Google or Cloudflare public DNS servers (8.8.8.8, 8.8.4.4, 1.1.1.1). This is well known and prevents resolution by NPA for all our configured private apps.
 
Based upon our testing (and trial and error) the following public DNS servers are working with NPA for our users and we must update our fleet of Macs as needed.
  • Comcast (Xfinity):  75.75.75.75, 75.75.76.76
  • AT&T:   68.94.156.1, 68.94.157.1
  • Frontier:  185.228.168.168, 185.228.169.168
  • Quad9 Public DNS Servers: 9.9.9.9, 149.112.112.112
  • Fortinet Public DNS servers : 208.91.112.52 , 208.91.112.53

 

I would like to suggest Netskope maintain a list of known good public DNS servers that work with NPA. This would include updating the list when necessary, due to services not working anymore, etc. In a Work From Home (WFH), traveling, or foreign work force environment, we consistently run into problems with access to private apps due to this issue. 
 
 As a final resolution I would like to recommend Netskope deploy and maintain public DNS servers that the NS Client would automatically use, with the option to disable as needed. Thoughts?

7 replies

qyost
Userlevel 5
Badge +16

That seems very peculiar, especially since the config docs reference opening access through your firewall to the Google DNS servers.   Is this just with NPA that you're seeing the issue?   If so, where are you doing the resolution, on the client or on the publisher? 

---Q.
J
Userlevel 2
Badge +5

We see this with NPA specifically. I have had multiple tickets open for this issue and the fix has always been to switch DNS providers on the Client side, which will over ride network based settings (router)..

C
Badge +7

Hi @jschuele,

Great article, thank you so much for posting it. We also have an issue with name resolution when some of our employees work remotely and use NPA. As we are gradually reducing our VPN usage, the NPA usage is gaining momentum but so are the intermittent DNS issues.

I have an active support case but they haven't yet been able to identify the cause.

You have provided some valuable information. Thank you!

C
Badge +7

We have identified are issues occur when our clients have IPv6 enabled and they get a Public Routable address (eg. IPv6 address starting with 2001:xxx). This occurs on certain ISP's (in our case Telstra) and when joining a hotspot on an Android phone. Disabling IPv6 on the wifi adapter is resolving the issue. We now need to decide whether or not to disable IPv6 on all laptop wifi adapters or fix on an ad-hoc basis...

 

N
Userlevel 4
Badge +12

Bumping this 4 month old thread for some clarification as there doesn’t seem to be any evidence to backup what is being talked about. 

What are the issues people are seeing? (We have NPA enabled with nearly everyone using Google DNS without issues). Are the issues with accessing cloud applications over NPA or internal applications? 

“This is well known and prevents resolution by NPA for all our configured private apps.”
I haven’t been able to find anything in the support portal about NPA and Google DNS not working. Can you point me to some articles so I can catch up?

Can you share the ticket numbers so I can get some feedback from our SE’s?

M
Rank
Userlevel 4
Badge +14

I want to make one comment on IPv6 issue - the best way to deal with that is to configure Windows Registry via GPO or some other script to prioritize IPv4 over IPv6 addresses in dual-stack scenarios:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows

 

While that doc references older versions of Windows, that registry entry/value is still applicable to all Windows versions in production today

M
Rank
Userlevel 4
Badge +14

Furthermore, on the original poster note, the issue was that on MacOS starting with Ventura, any public DNS server that was supporting encrypted DNS-over-TCP(DoT) would interfere with NPA.  And DoT DNS query would not be visible to NPA.  Since then, Netskope has developed deployed capability in the Netskope client to prevent MacOS endpoint from selecting DoT method of communication even if the destination DNS server supports it and fall back to the unencrypted DNS communication.   That is controlled by the tenant flag, but should be enabled by default in all tenants now. If you have a problem that the original poster describes, please contact support to verify that the flag is enabled on your tenant

Reply


Terms & ConditionsCookie settings