DevOps PeachPublic DNS zones
- A DNS zone holds every record of one domain (for example
example.com). The zone name is unique within a resource group; the same name elsewhere gets a different set of name servers. - Delegation: after creating the zone, take all 4 name servers Azure assigns (
az network dns zone show --query nameServers) and set them at the registrar. For a child zone (lab.example.com), add an NS record in the parent zone. - A record set is the records with the same name and the same type (for example two A records for
www); at most 20 records per set, no duplicates. - This is separate from verifying a custom domain for Entra ID (adding the TXT/MX record Entra gives you to the zone).
flowchart LR R["Registrar example.com"] -- "NS: ns1-01.azure-dns.com … ns4-01.azure-dns.info" --> Z["Azure DNS zone example.com"] Z --> W["www A 203.0.113.25"] P["Private zone lab.internal"] -- "VNet link (auto-registration)" --> V["vnet-lab"] %% step R: At the registrar, point the NS records for example.com to the four Azure DNS name servers. %% step Z: The Azure DNS zone example.com now answers queries for the domain. %% step W: A record set such as www A 203.0.113.25 maps the name to the public IP. %% step P: The private zone lab.internal resolves only inside VNets that are linked to it. %% step V: With auto-registration on the link, VMs in vnet-lab get their DNS records automatically.
Private DNS zones
- Resolve names inside a VNet and across linked VNets with your own domain (
lab.internal), no self-built DNS server, not reachable from the Internet. - You must link the zone to the VNet; turn on auto-registration so VMs get A records for their hostnames automatically.
- Reverse DNS (PTR) works only within the same VNet.
Traps: giving the registrar only 1–2 name servers; thinking a record set holds several record types; forgetting to link the private zone to the VNet.
| Command | Meaning |
|---|---|
az network dns zone create -g rg-devops-lab -n example.com |
Create a public zone |
az network private-dns zone create -g rg-devops-lab -n lab.internal |
Create a private zone |
az network private-dns link vnet create -g rg-devops-lab -z lab.internal -n link-vnet-lab -v vnet-lab -e true |
Link a VNet + auto-registration |
Record types
| Type | Holds | Example |
|---|---|---|
| A / AAAA | IPv4 / IPv6 address | www → 203.0.113.25 |
| CNAME | Alias to another name | shop → example-shop.azurewebsites.net |
| MX | Mail servers with priority | 10 mail.example.com |
| TXT | Free text, used for verification and SPF | v=spf1 include:spf.protection.outlook.com -all |
| NS / SOA | Delegation and zone authority | Created by Azure |
| SRV | Service location with port | SIP, LDAP |
| CAA | Which CAs may issue certificates | 0 issue "letsencrypt.org" |
| PTR | Reverse lookup | Private zones only in Azure |
A CNAME cannot sit at the zone apex (example.com itself). Azure alias records solve this: an A record that points to an Azure resource, such as a public IP, Front Door, or Traffic Manager profile, and updates itself when that resource's address changes.
TTL and changes
Each record set has a TTL in seconds that tells resolvers how long to cache it. Lower the TTL a day before a planned migration so the switch spreads quickly, then raise it again.
DNS inside a VNet
By default VMs use Azure-provided DNS at the virtual address 168.63.129.16, which resolves public names and VM names in the same VNet. You can instead set custom DNS servers on the VNet, for example domain controllers. For hybrid name resolution between on-premises and Azure private zones, Azure DNS Private Resolver provides inbound and outbound endpoints without running your own DNS VMs.
Checking resolution
nslookup www.example.com ns1-01.azure-dns.com asks Azure's name server directly, which tells you whether the record is right even before delegation has spread. dig +short NS example.com shows which name servers the internet currently uses.