Private endpoint not consistently resolving on-prem via Cisco Umbrella?

Question

I have set up private endpoint for various Azure resources (SQL Server, Web Apps etc.) and set up conditional forwarding to the Azure wire server within our DNS configuration.

A ping resolves to the private IP of the server (i.e. that of the private endpoint) when testing from Azure VM's within the VNET, but when testing from local machines, it seems to flip flop between returning the private IP and returning the public azure endpoint, meaning I can sometimes connect through to these resources from my machine (when the private IP is being returned) and sometimes not (when the public IP is being returned).

We have our local machines pointing at Cisco Umbrella for their DNS resolution already, and have therefore opted to have the relevant azure endpoints forward onto our VM-based DNS servers using Umbrella's in-built DNS forwarding capabilities.

If I test through this method I can replicate the issue, if I override this method using my hosts file (pointing the relevant URL's directly at their private endpoint IP address), it works consistently, suggesting the issue is with Cisco Umbrella, and it is not consistently handling the requests. I wanted to see if there was anything from the Azure side that may need to be re-configured to get this working.

Any ideas?

Answer 1

@Elliot Stansfield ,
Welcome to the Microsoft Q&A forum. Thank you for posting a detailed question.

I went through some similar issues internally and as correctly pointed out the issue can be related to Cisco Umbrella as it can override the DNS resolution as it needs to know which domains should be considered as internal. The issue was resolved after adding the internal domain to Cisco Umbrella 's domain management.

You can through this link regarding Umbrella's Domain Management feature and how to add the appropriate domains to the Internal Domains section of the dashboard.

Hope this helps! Please let me know if the issue still persists. Thank you!

Answer 2

To assist with troublshooting, I would open NSLOOKUP from the cmd prompt, type set debug=2 then the FQDN of the resource.

You'll be able to run multiple DNS lookups and see from the output if you have differing DNS servers resolving differently.

It won't resolve the issue, but may help you with where the incorrect resolutions are coming from