How DNS Works in Azure

DNS fundamentals recap

DNS translates hostnames (storage.mycompany.com) into IP addresses (10.0.2.5 or 52.168.1.10). The key components:

DNS records are entries in a zone that map names to values. An A record maps a hostname to an IPv4 address. A CNAME maps one hostname to another (an alias). An MX record specifies mail servers for a domain. A TXT record stores arbitrary text, commonly used for domain verification and SPF.

TTL (Time to Live) is the number of seconds a resolver caches a DNS response. A record with TTL 300 means resolvers and clients cache the answer for 5 minutes before querying again. Low TTLs mean faster propagation of changes; high TTLs reduce DNS query load. During a planned change (like moving a service to a new IP), lower the TTL days in advance so caches expire quickly when you make the switch.

DNS resolvers are the servers that answer queries. When you type a hostname, your OS queries a resolver (configured via DHCP or statically). The resolver either has the answer cached or walks up the DNS hierarchy to find it: root servers → TLD servers (.com) → authoritative name servers for the zone → the actual record.

Azure-provided DNS at 168.63.129.16

Azure’s built-in DNS server is available at the virtual IP 168.63.129.16. Every VM in every Azure VNet uses this as its DNS server by default. It is not a physical server at that address — it is a platform-level virtual IP that routes queries to Azure’s DNS infrastructure.

Azure-provided DNS resolves three categories of queries:

Azure internal hostnames. VMs receive an FQDN like vm-web-01.eastus.internal.cloudapp.net. Azure-provided DNS resolves this to the VM’s private IP within the same VNet. This works automatically without any configuration.

Private DNS zone records. When a Private DNS zone is linked to a VNet, Azure-provided DNS automatically serves records from that zone. A query for a hostname in the zone returns the private IP from the zone record. This is the mechanism behind Private Endpoints — the zone record overrides the public DNS response.

Public DNS. All other queries are forwarded to Azure’s recursive resolvers, which resolve public internet hostnames normally.

Azure DNS as a hosted zone service

Azure DNS is Azure’s authoritative DNS hosting service for public domains. When you host a zone in Azure DNS (for example, mycompany.com), Azure DNS becomes the authoritative name server for that domain. You manage all records through the Azure portal, CLI, or ARM/Terraform.

Azure DNS does not register domain names — you still need a registrar (GoDaddy, Namecheap, Google Domains). You update the NS records at your registrar to point to the Azure DNS name servers assigned to your zone. After that, all DNS queries for your domain go to Azure DNS.

Azure DNS is distinct from Private DNS Zones. Azure DNS serves public internet queries. Private DNS Zones serve internal VNet queries only.

DNS resolution chain for VMs

When a VM running in an Azure VNet resolves a hostname, the query follows this chain:

How Private Endpoints affect DNS

Private Endpoints change the DNS resolution behaviour for Azure services, and getting this wrong is one of the most common sources of “my private endpoint isn’t working” bugs.

Consider Azure Blob Storage. The storage account’s public hostname is mystorageaccount.blob.core.windows.net. Normally, this resolves to a public IP like 52.168.1.50. You create a Private Endpoint for the storage account in your VNet. The endpoint gets a private IP like 10.0.2.20.

For the private endpoint to work, DNS must return 10.0.2.20 for mystorageaccount.blob.core.windows.net when queried from within your VNet. Azure handles the public-to-private CNAME chain through mystorageaccount.privatelink.blob.core.windows.net. But the A record for that CNAME must exist in a Private DNS zone.

The required pieces: a Private DNS zone named privatelink.blob.core.windows.net, an A record in that zone mapping the storage account name to its private endpoint IP, and a VNet link connecting the zone to your VNet. Without the zone and VNet link, queries from inside the VNet still return the public IP — the private endpoint receives no traffic.

When you create a private endpoint through the portal with the recommended configuration, Azure automatically creates the Private DNS zone and record. When you create private endpoints via CLI or Terraform, you must create these DNS resources manually or through the DNS zone group resource.

Custom DNS servers and the 168.63.129.16 forwarding rule

When you set a custom DNS server on a VNet, Azure-provided DNS is bypassed. All DNS queries from VMs in that VNet go to your custom server instead of 168.63.129.16. This is necessary for hybrid environments where on-premises hostnames need to resolve.

The critical rule: any custom DNS server in Azure must forward unknown queries to 168.63.129.16. If it does not, VMs lose the ability to resolve Azure internal names, private DNS zones, and private endpoint records. The custom server handles what it knows (on-premises hostnames, split-horizon entries), and forwards everything else to Azure.

Split-horizon DNS

Split-horizon DNS returns different IP addresses for the same hostname depending on where the query originates. Internal clients querying from within the VNet get a private IP; external clients querying from the internet get a public IP.

Use case: api.mycompany.com should resolve to 10.0.2.10 for VMs inside Azure, but to 203.0.113.5 for external clients. Create a Private DNS zone named api.mycompany.com with an A record pointing to the private IP, and link it to the VNet. Simultaneously, keep the existing public Azure DNS zone with the public IP. Queries from within the VNet hit the private zone first (because of the VNet link); queries from the internet hit only the public zone.