Azure DNS: public and private zones

Nordlicht Reisen GmbH, a fictional travel agency, runs its booking portal under its own domain and wants its machines in the internal network to reach one another by name, without memorizing addresses. Azure DNS solves both: public zones for names the internet should resolve, and private zones for names that apply only in your virtual networks. The exam calls it configure Azure DNS.

Prior knowledge: What Azure DNS is appears in "AZ-900 compact," lesson 2.4. How DNS works (zones, records, resolution, caching) is taught in K3, lesson 3.0.3 ("DNS"); it is assumed here. Virtual networks are lesson 4.1. Where private zones are needed for private endpoints, lesson 4.4 showed the zone name.

Public zones

A DNS zone hosts all the records of a domain. Azure DNS is the service that runs this zone on Microsoft's name servers. Azure DNS is not a registrar: you buy and renew the domain itself wherever you get it; only its records live in Azure DNS.

For the internet to query the zone, you must delegate the domain: at the registrar you enter the name servers (NS) that Azure assigned to your zone. Until then, resolvers on the internet don't resolve your names in this zone, even if the zone already has all the records.

In Azure DNS you give records relative names: the name www in the zone example.com yields www.example.com. The name @ stands for the top of the zone (the zone apex, example.com itself).

Azure DNS supports the common types:

Several records with the same name and type form a record set, for example two A records for www. The TTL (time to live, how long resolvers keep a record) can be set per set; Microsoft's CLI example shows 3600 seconds as the default.

Portal route: DNS zones → Create, subscription, resource group, name of the zone → Review + create. In the zone, + Record set: name, type, TTL, value. The portal names depend on the language setting.

Commands (Microsoft's example, with example.com instead of contoso.xyz):

az network dns zone create -g <gruppe> -n example.com
az network dns record-set a add-record -g <gruppe> -z example.com -n www -a 10.10.10.10
az network dns record-set list -g <gruppe> -z example.com
az network dns record-set ns show --resource-group <gruppe> --zone-name example.com `
  --name @

The last line names the zone's name servers. Those are the names you enter at the registrar. With Azure PowerShell, the counterparts are New-AzDnsZone and New-AzDnsRecordSet with New-AzDnsRecordConfig.

Checking with nslookup

As long as delegation is missing, you query one of the zone's name servers directly:

nslookup www.example.com <namensserver-der-zone>

The server's name comes from the NS output; Microsoft's example writes it in the form ns1-08.azure-dns.com.. The answer contains the name and the address you entered. That proves the zone is correct; whether the internet uses it depends on delegation.

Alias records

An alias record is an A, AAAA or CNAME record that points to an Azure resource instead of carrying a fixed address or a fixed name, for example a public IP address or a Traffic Manager profile. Three advantages according to Microsoft:

• If the resource's address changes, the record follows automatically.
• If the resource is deleted, the alias set becomes empty; no dangling record pointing to a foreign address is left behind.
• It works at the zone apex, where a CNAME is forbidden by the DNS rules. That solves the classic case of example.com without www.

Alias records cost nothing extra. They require the resource provider Microsoft.Network to be registered in the subscription (az provider register --namespace Microsoft.Network). Portal route: + Record set, Alias record set to Yes, Alias type Azure resource or Zone record set, choose the resource.