Fix Azure Private Endpoint DNS issues where names resolve to public IPs, return NXDOMAIN, or fail from Azure or on-premises clients.
Start with Check the service FQDN and work through the six diagnostic checks in order.
Record results before changing configuration and validate the original symptom after each controlled change.
Quick checks
Start with the basic checks in this runbook before moving to deeper troubleshooting.
- Confirm the affected service or component is available.
- Check recent configuration or connectivity changes.
- Run the relevant commands and compare the result with the expected state.
Check the service FQDN
Resolve the service FQDN from the affected network and compare the returned address with the private endpoint IP.
Check the Private DNS zone
Confirm the required privatelink zone and A record exist and are associated with the correct Azure resource.
Check VNet links
Verify the Private DNS zone is linked to every VNet from which clients need to resolve the name.
Check custom DNS forwarding
Check custom DNS servers, conditional forwarding and forwarding paths for the private-link namespace.
Check NXDOMAIN and stale records
Investigate NXDOMAIN or unexpected answers caused by missing records or an overriding private zone.
Flush and retest
Flush the client DNS cache and repeat the query from the same source network.
Useful commands
Run these checks from an appropriate administrative session and replace example values with your environment.
DNS lookup
Resolve-DnsName <service-fqdn>Private DNS zones
Get-AzPrivateDnsZone -ResourceGroupName <resource-group>Quick troubleshooting path
Use this sequence to isolate the failing dependency before changing production configuration.
- Check the service FQDN → Resolve the service FQDN from the affected network and compare the returned address with the private endpoint IP.
- Check the Private DNS zone → Confirm the required privatelink zone and A record exist and are associated with the correct Azure resource.
- Check VNet links → Verify the Private DNS zone is linked to every VNet from which clients need to resolve the name.
- Check custom DNS forwarding → Check custom DNS servers, conditional forwarding and forwarding paths for the private-link namespace.
- Check NXDOMAIN and stale records → Investigate NXDOMAIN or unexpected answers caused by missing records or an overriding private zone.
- Flush and retest → Flush the client DNS cache and repeat the query from the same source network.
What good troubleshooting looks like
Good infrastructure troubleshooting is evidence-driven. Capture the original state, test the dependency that can prove or disprove your hypothesis, make the smallest safe change and repeat the original test.
Symptom → hypothesis → direct test → result → controlled change → validation → documentation