When you deploy resources into Azure Virtual Networks (VNets), one of the first critical services they rely on is DNS. Without proper name resolution, services can’t communicate, authenticate, or scale dynamically.

By default, every Azure VNet is configured with Azure-provided DNS, a fully managed, highly available service that just works — but it’s important to understand how it functions, where it shines, and when you might need something more advanced.

In this blog, we’ll explore how Azure-provided DNS works, where it fits into your network architecture, and how to visualize and test it. We’ll also walk through deploying a VM using Bicep, and include a helpful Mermaid diagram to make the DNS resolution process clear.

What is Azure-provided DNS?

Azure-provided DNS is a free, built-in DNS service automatically enabled for all Azure VNets. It allows resources inside a VNet to resolve:

• Internal Azure names (e.g., VMs in the same VNet or peered VNets)
• Public internet names via recursive lookup

Azure’s DNS service runs at a well-known virtual IP address:

168.63.129.16

All Azure VMs automatically configure this IP as their DNS server unless you override it with custom settings.

How Azure-provided DNS Works

• Dynamic DNS Suffix Assignment: Every VNet gets a default DNS suffix (e.g., xyz.internal.cloudapp.net) automatically. Azure VMs registered to that VNet are reachable by their hostname plus this suffix.
• Internal Name Resolution: VMs in the same VNet can resolve each other’s hostnames automatically.
• Recursive Internet Name Resolution: Azure forwards public DNS queries to external authoritative servers for you.
• Automatic Updates: If a VM’s IP changes (e.g., deallocated/reallocated), Azure updates its internal records automatically.

Limitations of Azure-provided DNS

While Azure-provided DNS is simple and effective for many scenarios, it has limitations:

Visualizing Azure-provided DNS Resolution

Here’s a diagram showing a simple DNS flow for VMs using Azure-provided DNS:

Viewing and Testing Azure-provided DNS in the Portal

Step 1: View DNS Settings in a VNet

1. Open the Azure Portal.
2. Go to Virtual Networks.
3. Select your VNet (e.g., myVNet).
4. Under Settings, choose DNS Servers.
5. Verify that the setting is set to Default (Azure-provided).

Step 2: Deploy a Test VM

1. Create a new VM inside the same VNet (myVNet).
2. SSH or RDP into the VM once deployed.

Step 3: Test DNS Resolution

• Open a terminal or PowerShell session.

• Run:

  1	nslookup <another-vm-name>

• The DNS server should show as 168.63.129.16, and you should receive an internal IP address.

You can also test external resolution:

1

nslookup microsoft.com

Deploying a VNet and VM Using Bicep

Here’s a simple Bicep file to create a VNet and VM relying on Azure-provided DNS:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

@description('Name of the Virtual Network')
param vnetName string = 'myVNet'

@description('Name of the Virtual Machine')
param vmName string = 'myVM'

@description('Username for the Virtual Machine')
param adminUsername string = 'azureuser'

@description('Password for the Virtual Machine')
@secure()
param adminPassword string = 'P@ssword1234!'

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' = {
  name: vnetName
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: 'myVMsubnet'
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
    ]
  }
}

resource nic 'Microsoft.Network/networkInterfaces@2024-05-01' = {
  name: '${vmName}-nic'
  location: resourceGroup().location
  properties: {
    ipConfigurations: [
      {
        name: 'ipconfig1'
        properties: {
          subnet: {
            id: vnet.properties.subnets[0].id
          }
          privateIPAllocationMethod: 'Dynamic'
        }
      }
    ]
  }
}

resource vm 'Microsoft.Compute/virtualMachines@2024-11-01' = {
  name: vmName
  location: resourceGroup().location
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_B1s'
    }
    osProfile: {
      computerName: vmName
      adminUsername: adminUsername
      adminPassword: adminPassword
    }
    storageProfile: {
      imageReference: {
        publisher: 'Canonical'
        offer: 'UbuntuServer'
        sku: '18.04-LTS'
        version: 'latest'
      }
      osDisk: {
        createOption: 'FromImage'
      }
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: nic.id
        }
      ]
    }
  }
}

Pros and Cons of Azure-provided DNS

Common Scenarios for Azure-provided DNS

• Small to medium workloads: Where internal resolution of VM names is sufficient.
• Development and test environments: Quick setup without worrying about DNS infrastructure.
• Simple hub-and-spoke networks: As long as VNet peering is configured correctly.
• Starting point for hybrid networks: Before moving to Private DNS and Private Resolver.

Learn More

• Name resolution for VMs and role instances
• Azure Virtual Network DNS settings
• Configure DNS settings for a virtual network