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? 

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)..

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!

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...

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?

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

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