DNS Resolution Problems in Azure

The four DNS failure patterns in Azure

Before diagnosing, identify which failure pattern you are seeing:

1. VM cannot resolve public DNS — the VM cannot reach external websites or resolve Azure service endpoints. Usually a custom DNS server on the VNet that is misconfigured or unreachable.
2. Private endpoint resolves to public IP — a service with a private endpoint returns its public IP instead of the private IP, causing connections to fail or bypass the private network path.
3. Split-horizon DNS not working — a DNS name should resolve differently from inside the VNet versus outside, but it resolves the same from both places.
4. DNS caching causing stale resolution during migration — after reconfiguring DNS (changing from public to private endpoint, changing a VNet’s DNS server), VMs continue using the old cached answer until the TTL expires.

The diagnostic starting point for all four patterns is the same: run nslookup from inside the affected VM.

Testing DNS resolution from inside a VM

SSH into the VM and run basic DNS diagnostics:

# Test basic public DNS resolution
nslookup google.com
nslookup google.com 168.63.129.16  # Force Azure DNS

# Test a private endpoint resource
nslookup myaccount.blob.core.windows.net
nslookup myaccount.blob.core.windows.net 168.63.129.16

# Check which DNS server the VM is configured to use
cat /etc/resolv.conf
# or on newer Ubuntu
resolvectl status

# Verbose nslookup showing full resolution path
nslookup -debug myaccount.blob.core.windows.net

On Windows VMs:

# Test DNS resolution
Resolve-DnsName myaccount.blob.core.windows.net
Resolve-DnsName myaccount.blob.core.windows.net -Server 168.63.129.16

# Show DNS client configuration
Get-DnsClientServerAddress
ipconfig /all | findstr "DNS Servers"

# Flush DNS cache
ipconfig /flushdns

The key question is whether the resolved IP is a private IP (10.x.x.x or 172.16.x.x or 192.168.x.x) or a public IP. For private endpoint resources, it must be a private IP.

Failure 1: VM cannot resolve public DNS

If nslookup times out for public names but other VMs in the same region work, the VNet has a custom DNS server configured that is either unreachable or misconfigured.

Check the DNS server configuration on the VNet:

az network vnet show \
  --resource-group myResourceGroup \
  --name myVNet \
  --query "dhcpOptions.dnsServers" \
  --output json

If this returns a list of IP addresses (e.g., ["10.1.1.4"]), the VNet is using a custom DNS server. That server must:

1. Be reachable from the VNet on port 53 (UDP and TCP)
2. Be running and accepting queries
3. Forward unresolved queries to Azure DNS (168.63.129.16) to resolve Azure internal names

Test if the custom DNS server is reachable from the VM:

# Test UDP DNS port
nc -u -z -v 10.1.1.4 53

# Test a query against the custom server directly
nslookup google.com 10.1.1.4

To fall back to Azure DNS temporarily, reset the VNet DNS configuration to default:

az network vnet update \
  --resource-group myResourceGroup \
  --name myVNet \
  --dns-servers ""

VMs must be restarted or their DHCP leases renewed to pick up the new DNS server after a VNet change.

Failure 2: Private endpoint resolving to public IP

When a service like Azure Blob Storage has a private endpoint configured but nslookup still returns the public IP, the private DNS zone is missing, not linked, or the VM is not using Azure DNS.

The resolution chain for private endpoints requires all of the following:

1. A private DNS zone named privatelink.blob.core.windows.net (for Blob Storage)
2. An A record in that zone pointing myaccount to the private IP
3. A VNet link connecting the private DNS zone to the VNet containing the VM
4. The VM using Azure DNS (168.63.129.16) directly or via a forwarder

Check if the private DNS zone exists and is linked:

# List all private DNS zones in the resource group
az network private-dns zone list \
  --resource-group myResourceGroup \
  --output table

# Check VNet links for the relevant zone
az network private-dns link vnet list \
  --resource-group myResourceGroup \
  --zone-name privatelink.blob.core.windows.net \
  --output table

Check A records in the zone:

az network private-dns record-set a list \
  --resource-group myResourceGroup \
  --zone-name privatelink.blob.core.windows.net \
  --output table

Expected output should show myaccount with an IP in the VNet’s private range. If the A record is missing, the private endpoint’s DNS configuration was not set up when the endpoint was created. Re-create the private endpoint with automatic DNS integration enabled:

az network private-endpoint create \
  --resource-group myResourceGroup \
  --name myBlobPrivateEndpoint \
  --vnet-name myVNet \
  --subnet mySubnet \
  --private-connection-resource-id "/subscriptions/$SUB_ID/resourceGroups/$RG/providers/Microsoft.Storage/storageAccounts/myaccount" \
  --connection-name myBlobConnection \
  --group-id blob \
  --private-dns-zone-group-name "blobPrivateDnsZoneGroup" \
  --private-dns-zones "privatelink.blob.core.windows.net"

Failure 3: Split-horizon DNS not resolving correctly

Split-horizon DNS serves different answers for the same name depending on whether the query comes from inside or outside the VNet. Azure achieves this with private DNS zones. If both inside and outside the VNet get the same (public) answer, the conditional forwarder on the custom DNS server is missing.

In an architecture where a custom DNS server (Windows DNS server or BIND on a VM) is used:

1. The VNet’s DNS server points to the custom server (e.g., 10.1.1.4)
2. The custom server must have a conditional forwarder for the private zone names
3. That forwarder must point to Azure DNS at 168.63.129.16

Without the conditional forwarder, the custom server resolves public DNS names using its upstream public DNS resolvers and never consults Azure’s private DNS zones.

On a Windows DNS server (run via PowerShell):

# Add conditional forwarder for private endpoint zones
Add-DnsServerConditionalForwarderZone `
  -Name "privatelink.blob.core.windows.net" `
  -MasterServers 168.63.129.16

Add-DnsServerConditionalForwarderZone `
  -Name "privatelink.database.windows.net" `
  -MasterServers 168.63.129.16

Add-DnsServerConditionalForwarderZone `
  -Name "privatelink.vaultcore.azure.net" `
  -MasterServers 168.63.129.16

On a BIND server (add to named.conf):

zone "privatelink.blob.core.windows.net" {
  type forward;
  forwarders { 168.63.129.16; };
};

After adding the conditional forwarder, flush the DNS cache on the custom server and test from the VM.

Failure 4: DNS caching during migration

When you change from a public endpoint to a private endpoint, or when you change the VNet’s DNS server, existing VMs continue using the cached DNS answer until the TTL expires. Azure DNS zones have a default TTL of 3600 seconds (1 hour).

Public Azure service DNS names (like myaccount.blob.core.windows.net) resolve via CNAME to a privatelink name. The CNAME TTL on the public side is typically 60 seconds. However, the final A record answer may be cached by the OS or by an intermediate DNS resolver for its full TTL.

Force a DNS cache flush on Linux:

# If using systemd-resolved
sudo systemd-resolve --flush-caches
sudo resolvectl flush-caches

# If using dnsmasq
sudo killall -HUP dnsmasq

# Direct nscd cache flush
sudo nscd -i hosts

On Windows:

ipconfig /flushdns
Clear-DnsClientCache

During a migration where both public and private endpoints coexist, keep the TTL low (60 seconds) until the migration is complete, then raise it back to production levels. Change the TTL on private DNS zone records:

az network private-dns record-set a update \
  --resource-group myResourceGroup \
  --zone-name privatelink.blob.core.windows.net \
  --record-set-name myaccount \
  --set ttl=60