Cloud / Azure DNS Interview questions

Azure DNS is a hosting service for DNS domains that runs on Microsoft's global network of name servers. You create a zone, add records, and Azure answers queries for your domain from the closest available server.

It is managed with the same tools as any other Azure resource: portal, CLI, PowerShell, REST API, SDKs and ARM/Bicep templates. That means Azure RBAC, activity logs and resource locks all apply to your DNS data.

Azure DNS is not a domain registrar. You still buy the domain elsewhere (for example App Service Domains or a third-party registrar) and then point it at Azure's name servers. It offers a 99.99% availability SLA for DNS queries and has two flavors: public zones for internet names and private zones for names inside virtual networks.

A DNS zone is the container for all DNS records of one domain name, such as contoso.com, and its child names unless those are delegated elsewhere.

When you create a zone in Azure DNS, it automatically contains an SOA record and four NS records at the apex. The NS records list the Azure name servers that are authoritative for the zone.

A zone is created inside a resource group, and its location is always global. Zone names must be unique within a resource group, but the same name can exist in different resource groups or subscriptions, each getting different name servers.

Azure DNS supports the common record types: A, AAAA, CAA, CNAME, DS, MX, NAPTR, NS, PTR, SOA, SRV, TLSA and TXT.

Records with the same name and type form a record set, which is the unit you manage in Azure. Wildcard records such as *.contoso.com are supported for all types except NS and SOA.

An Azure Private DNS zone provides name resolution inside one or more virtual networks without you running any DNS servers. Records in it are not reachable from the internet.

You create the zone (for example corp.contoso.internal), then link it to virtual networks. VMs in a linked VNet resolve its records through the Azure-provided resolver.

Private zones can use any name, including names that are not registered on the internet. They support the usual record types except NS and SOA edits at the apex, and they can auto-register VM records in one linked VNet.

Every public zone is assigned four name servers from Azure's pool, such as ns1-01.azure-dns.com, ns2-01.azure-dns.net, ns3-01.azure-dns.org and ns4-01.azure-dns.info.

They appear as NS records at the zone apex. These are the names you give your domain registrar so the internet knows Azure is authoritative for your domain.

az network dns zone show -g rg-dns -n contoso.com --query nameServers -o tsv

The four names come from four different top-level domains (.com, .net, .org, .info), so an outage affecting one TLD does not stop resolution.

TTL (time to live) is the number of seconds that resolvers and clients may cache a DNS answer before asking again.

A long TTL (such as 3600 seconds, a common default) cuts query volume and speeds up lookups, but changes spread slowly. A short TTL (30-300 seconds) lets changes and failovers propagate quickly at the cost of more queries.

az network dns record-set a create -g rg-dns -z contoso.com -n www --ttl 300

Before planned changes such as migrations, lower the TTL ahead of time, at least as long as the old TTL, so caches drain.

An alias record is an A, AAAA or CNAME record set that points to an Azure resource instead of a fixed value. Supported targets include a public IP address, a Traffic Manager profile, an Azure Front Door endpoint, a CDN endpoint, or another record set in the same zone.

Azure keeps the answer in sync with the target. If a public IP changes, the DNS answer changes with it, with no manual edit.

Alias records also work at the zone apex (for example contoso.com), where a normal CNAME is not allowed, and queries answered by alias records pointing to Azure resources are free.

The SOA (Start of Authority) record identifies the primary name server of a zone and holds zone-level parameters: responsible email, serial number and the refresh, retry, expire and minimum TTL timers.

Azure creates it automatically with the zone and you cannot delete it. You can change most fields (such as the email and timers) but not the host name. The minimum TTL value controls how long resolvers cache negative answers (NXDOMAIN).

SOA fields matter mostly for zone transfers between traditional servers. Azure DNS does not use secondary zone transfers, so in practice you rarely touch it.

Create the resource group first, then the zone with az network dns zone create. Fetch the name servers afterwards so you can delegate the domain.

az group create -n rg-dns -l eastus
az network dns zone create -g rg-dns -n contoso.com
az network dns zone show -g rg-dns -n contoso.com --query nameServers

For a private zone, use the private-dns command group instead:

az network private-dns zone create -g rg-dns -n corp.contoso.internal

You can also create the zone with PowerShell (New-AzDnsZone) or the portal. Zone creation is quick, but nothing resolves from the internet until the domain's name servers at the registrar point to the new zone.

Records are added to a record set. Create the set, then add the IP address to it. The CLI can do both in one call with add-record.

az network dns record-set a add-record \
  -g rg-dns -z contoso.com -n www -a 20.50.1.10

az network dns record-set a list -g rg-dns -z contoso.com -o table

Use -n @ for a record at the zone apex. In PowerShell, the equivalent is New-AzDnsRecordSet with -DnsRecords (New-AzDnsRecordConfig -IPv4Address ...).

Use az network dns record-set a list to confirm what was created. Adding a second IP to the same name creates a multi-value record set, which gives simple round-robin style answers.

Azure DNS Private Resolver is a managed service that lets you resolve DNS queries between Azure and other networks without managing DNS server VMs.

• Inbound endpoint: a private IP in your VNet that on-premises or other networks can send queries to, so they can resolve private zone names.
• Outbound endpoint: a subnet used to send queries from Azure to external DNS servers, driven by forwarding rules.
• Forwarding ruleset: rules that map domain names to target DNS servers.

Each endpoint needs its own dedicated subnet delegated to Microsoft.Network/dnsResolvers. It is zone-redundant where supported, so it replaces BIND or Windows DNS forwarder VMs.

A CNAME (canonical name) record makes one name an alias of another name. A resolver that gets a CNAME answer repeats the lookup for the target name.

www.contoso.com.   300  IN  CNAME  contoso.azurewebsites.net.

Two rules matter. A CNAME cannot exist at the zone apex, and a name with a CNAME cannot have other record types beside it (so you cannot also add MX to mail.contoso.com if it is a CNAME). In Azure DNS a CNAME record set holds exactly one record.

A virtual network link connects a private DNS zone to a VNet so that resources in the VNet can resolve the zone's records.

Each link has an option for auto-registration. With it enabled, VMs in the VNet register their names in the zone automatically. A VNet can be linked to many zones for resolution, but only one zone as a registration zone.

az network private-dns link vnet create -g rg-dns -n link-hub \
  -z corp.contoso.internal -v vnet-hub -e true

Delegation hands authority for a domain or subdomain to a different set of name servers. It works by adding NS records in the parent zone that point to the child's name servers.

For a domain hosted in Azure DNS, you set the registrar's name server list to the four Azure name servers. For a subdomain such as dev.contoso.com, you create a separate Azure zone and add its NS records into the contoso.com zone under the name dev.

Until delegation is in place, resolvers on the internet never ask Azure about your domain, even if the zone is full of records.

168.63.129.16 is a virtual public IP address owned by Azure that provides platform services to VMs inside a VNet. For DNS, it is the address of the Azure-provided resolver.

By default, VMs send DNS queries to it. It answers for private DNS zones linked to the VNet, resolves Azure internal VM names, and recurses to the internet for everything else.

It is reachable only from inside Azure virtual networks, not from on-premises. Custom DNS servers in Azure forward to it to resolve private zone names, and you should not block it in NSG or firewall rules.

A public zone answers anyone on the internet. A private zone answers only the virtual networks linked to it.

Both can share the same domain name. That setup is called split-horizon DNS and lets internal clients get private IPs while internet users get public ones.

Azure DNS hosts your DNS records. Traffic Manager is a DNS-based traffic router that decides which endpoint to return for a name based on a routing method and health checks.

They are used together: you host contoso.com in Azure DNS and point app.contoso.com to a Traffic Manager profile, using a CNAME, or an alias record at the apex. Traffic Manager never sees your traffic, only the DNS lookup.

Both point one name at another, but an alias record is an Azure-specific feature that targets Azure resources directly.

Prefer alias records for Azure targets such as Front Door, Traffic Manager and public IPs.

Delegation moves authority from your registrar's name servers to Azure's.

1. Create the public zone in Azure DNS and add your records.
2. Read the four name servers from the zone (az network dns zone show --query nameServers).
3. Log in at the registrar and replace the domain's name servers with those four values.
4. Wait for registrar and TLD caches (NS TTLs are often 24-48 hours).
5. Verify with nslookup -type=NS contoso.com.

nslookup -type=NS contoso.com
dig NS contoso.com +short

Do not delete the old zone until the new delegation is visible everywhere, and make sure all records exist in Azure first, or the cutover will break services.

When a VNet link has auto-registration enabled, Azure creates a DNS A record in the private zone for each VM's primary network interface in that VNet, named after the VM's hostname.

• The record is deleted when the VM is deleted.
• If the VM's IP changes, the record is updated.
• Only one private zone can be the registration zone for a VNet.
• Records you create manually stay separate from auto-registered ones.
• Registration applies to VMs; other resources, such as private endpoints, need their own records.

It removes the toil of updating DNS for every VM. For stable service names, create CNAMEs pointing at the auto-registered VM name.

Send queries for on-premises domains from Azure to your on-premises DNS servers using the outbound endpoint of Azure DNS Private Resolver and a forwarding ruleset.

1. Create a Private Resolver with an outbound endpoint in a delegated subnet.
2. Create a forwarding ruleset and add a rule such as corp.contoso.local. forwarding to the on-premises DNS IPs.
3. Link the ruleset to the VNets that need this resolution.
4. Make sure VPN or ExpressRoute lets the outbound subnet reach the on-premises DNS servers on port 53.

Before the resolver existed, this was done with a DNS forwarder VM and a custom DNS server setting on the VNet.

On-premises servers cannot query 168.63.129.16. Instead, they forward queries to the inbound endpoint of an Azure DNS Private Resolver, which resolves them using the private zones linked to its VNet.

1. Deploy a Private Resolver with an inbound endpoint (it gets a private IP).
2. Link the private zones to the resolver's VNet.
3. On the on-premises DNS server, create a conditional forwarder for the domain to the inbound IP.
4. Ensure connectivity (VPN or ExpressRoute) and allow DNS traffic.

For private endpoint names, forward the public zone name (for example blob.core.windows.net) to the inbound IP rather than the privatelink name, so the CNAME chain still resolves correctly.

A DNS forwarding ruleset is a group of rules used by a Private Resolver outbound endpoint to decide where to send queries for particular domains.

Each rule has a domain name (ending with a dot), a state (enabled or disabled) and one or more target DNS server IPs. The most specific matching domain wins. A rule for . acts as a catch-all.

az dns-resolver forwarding-rule create -g rg-dns \
  --ruleset-name rs-main -n onprem --domain-name "corp.contoso.local." \
  --forwarding-rule-state Enabled \
  --target-dns-servers '[{"ip-address":"10.10.0.4","port":53}]'

A ruleset is linked to VNets, and queries from those VNets get the rules applied. Rulesets are tied to outbound endpoints.

The zone apex already carries SOA and NS records, and DNS rules say a name with a CNAME cannot hold any other record type. A CNAME at contoso.com would conflict with those mandatory records and with MX or TXT records on the same name.

This is a problem when you want contoso.com itself to point to something like a Front Door endpoint or Traffic Manager profile, which only offer hostnames.

Azure solves it with alias records: an A or AAAA alias at the apex that resolves the target's current IPs inside Azure DNS and returns normal address records to clients. Other providers use proprietary ALIAS or ANAME flattening for the same reason.

Azure DNS uses standard Azure RBAC. Two built-in roles matter: DNS Zone Contributor for public zones and Private DNS Zone Contributor for private ones. Both let a user manage zones and record sets but not grant access to others.

• Assign roles at subscription, resource group, zone or even a single record set scope.
• Use custom roles to allow only certain record types, for example a team that may edit TXT records for domain validation but not A records.
• Reader roles allow viewing without changes.
• Combine with the activity log to see who changed what.

Keep production zones in a dedicated resource group so a broad contributor role on an application group never touches DNS.

A DNS zone deletion can take down every service using that domain. A CanNotDelete lock on the zone prevents accidental deletion of the zone, even by owners, until the lock is removed.

Zone-level locks do not stop individual record changes. To protect critical records such as the apex NS and SOA, apply a lock to the record set itself. A ReadOnly lock on a record set blocks edits and deletion.

az lock create -n protect-zone --lock-type CanNotDelete \
  -g rg-dns --resource-name contoso.com \
  --resource-type Microsoft.Network/dnsZones

Locks are a safety net, not access control, so use them alongside RBAC. Remember that anyone with permission can remove a lock, so restrict the Microsoft.Authorization/locks/delete permission to a small admin group, and document which records are locked and why.

A private endpoint gives a PaaS resource a private IP in your VNet. DNS must return that IP instead of the service's public one, which is done with a privatelink private zone.

flowchart LR
  VM["VM in VNet"] --> R["Azure resolver 168.63.129.16"]
  R --> Z["Private zone privatelink.blob.core.windows.net"]
  Z --> A["A record: 10.1.0.5"]
  A --> PE["Private endpoint IP"]

The public name mystore.blob.core.windows.net becomes a CNAME to mystore.privatelink.blob.core.windows.net. In a VNet linked to the private zone, that name resolves to the endpoint's private IP. Elsewhere it resolves to the public IP.

A DNS zone group on the private endpoint creates and maintains the A record automatically.

Split-horizon DNS returns different answers for the same name depending on where the query comes from. In Azure, you create a public zone and a private zone with the same name, such as contoso.com.

Clients in VNets linked to the private zone get private IP addresses. Everyone else gets the public answers from the public zone.

The catch: once a private zone contoso.com is linked to a VNet, names missing from the private zone return NXDOMAIN to that VNet instead of falling back to the public zone. Duplicate every record the internal clients still need, or use a newer VNet link option that falls back to internet resolution on NXDOMAIN where available.

By default a VNet uses Azure-provided DNS. You can override this in the VNet's DNS servers setting with your own server IPs, for example a domain controller or a Private Resolver inbound IP.

• VMs get the new DNS servers through DHCP, so they must renew the lease or restart.
• Your custom server must forward unknown names to 168.63.129.16 (or use the resolver) to resolve private zone and Azure internal names.
• Each VNet has its own setting; peered VNets do not inherit it.
• If the custom server is down, VMs in the VNet lose name resolution.

Run at least two custom DNS servers in different availability zones for resilience.

Yes. Azure DNS supports DNSSEC zone signing for public zones. Signing adds cryptographic signatures so validating resolvers can detect spoofed or tampered answers.

1. Sign the zone (portal, az network dns dnssec-config create, or PowerShell).
2. Copy the generated DS record details.
3. Add the DS record at the parent zone or registrar to complete the chain of trust.

az network dns dnssec-config create -g rg-dns --zone-name contoso.com
dig contoso.com DS +dnssec

Azure rolls the zone signing key automatically. Private zones are not covered. Because DNSSEC wording in docs has used preview labels, check the current status page before promising it for regulated workloads.

Use metrics, activity logs and, for VNet queries, DNS query logging.

Alert on unexpected deletions in the activity log and on sudden query-volume jumps, which can signal misconfiguration or abuse.

Metrics can be viewed per zone in the portal and routed to Log Analytics through diagnostic settings. Record set capacity metrics also warn you before a zone nears its limits, which is useful for large zones with many auto-generated records.

Export the zone file from the current provider, import it into Azure DNS, verify, then change the delegation.

1. Export the zone as a BIND-format zone file.
2. Create the zone and import it: az network dns zone import.
3. Review records; Azure does not import unsupported or provider-specific types.
4. Test using the Azure name servers directly with nslookup name ns1-xx.azure-dns.com.
5. Change NS at the registrar, then monitor and keep the old zone until TTLs expire.

az network dns zone import -g rg-dns -n contoso.com -f contoso.com.txt
az network dns zone export -g rg-dns -n contoso.com -f backup.txt

Large migrations should be rehearsed in a test zone first. Compare record counts and values between the source and Azure with a script that queries both name servers, so missing or mismatched records show up before you change delegation at the registrar.

You add DNS records so that the name points at the app and Azure can verify you own it.

• Subdomain (www): CNAME to app.azurewebsites.net plus a TXT record asuid.www with the app's custom domain verification ID.
• Apex (contoso.com): an A record to the app's inbound IP, or an alias to a supported resource, plus a TXT record asuid.
• Then add the hostname in the App Service portal and bind a certificate.

az network dns record-set txt add-record -g rg-dns -z contoso.com \
  -n asuid.www -v &quot;<verification-id>&quot;
az network dns record-set cname set-record -g rg-dns -z contoso.com \
  -n www -c myapp.azurewebsites.net

The asuid TXT record also prevents others from claiming your subdomain on a different app.

Declare the zone and record sets as resources of type Microsoft.Network/dnsZones. Zones always use location global.

resource zone 'Microsoft.Network/dnsZones@2018-05-01' = {
  name: 'contoso.com'
  location: 'global'
}

resource www 'Microsoft.Network/dnsZones/A@2018-05-01' = {
  parent: zone
  name: 'www'
  properties: {
    TTL: 300
    ARecords: [ { ipv4Address: '20.50.1.10' } ]
  }
}

Keeping DNS in IaC gives you reviewable pull requests, drift detection and repeatable zones across environments. Private zones use Microsoft.Network/privateDnsZones with child virtualNetworkLinks.

Parameterize the zone name, TTLs and IPs so one template serves dev, test and production. Private zones follow the same pattern: deploy the zone, then virtualNetworkLinks children with registrationEnabled set per link. Run az deployment group what-if in pipelines to preview DNS changes before they reach production.

Azure DNS runs on a global network of name servers using anycast. Queries go to the nearest healthy server, so latency stays low and a failure in one location is routed around.

Each zone gets four name servers on four different TLDs, so resolvers have independent paths. The service is backed by a 99.99% availability SLA for DNS queries.

Because zone data is replicated across the network, you do not manage secondaries or zone transfers. Your part of availability is correct delegation, sensible TTLs, and protecting zones from accidental changes with locks and RBAC.

Availability of your own application still depends on correct records. Use health-aware routing such as Traffic Manager or Front Door for application failover, since Azure DNS itself returns the records you configured regardless of backend health.

With default settings, a VM resolves names through the Azure-provided resolver.

flowchart LR
  A["App on VM"] --> S["OS stub resolver and cache"]
  S --> R["Azure resolver 168.63.129.16"]
  R --> P{Linked private zone has the name?}
  P -- Yes --> PR["Return private record"]
  P -- No --> I{Azure internal name?}
  I -- Yes --> IR["Return internal.cloudapp.net answer"]
  I -- No --> N["Recursive lookup on public DNS"]

1. The application asks the OS resolver, which checks its local cache.
2. On a miss, the query goes to the DNS server set in the VNet DHCP options, by default 168.63.129.16.
3. Azure checks private zones linked to the VNet, then internal VM names.
4. Anything else is resolved recursively using public DNS.

If custom DNS servers are configured, step 2 goes to them first, and they must forward to Azure for private names.

The name resolves publicly when the client's DNS path never reaches the privatelink zone. Typical causes:

• The private DNS zone is not linked to the VNet where the query is made.
• The VNet uses a custom DNS server that doesn't forward to 168.63.129.16 or to the Private Resolver.
• The client is on-premises and its DNS server has no conditional forwarder to Azure.
• The A record is missing, because the private endpoint has no DNS zone group.
• The client has a stale cached answer from before the endpoint was created.

nslookup mystore.blob.core.windows.net
# Expect: CNAME mystore.privatelink.blob.core.windows.net -> 10.1.0.5

Fix the cause, then flush caches. If the answer is still public, test with nslookup name 168.63.129.16 from an Azure VM to separate resolver problems from client problems.

Centralize DNS in the hub so spokes stay simple and consistent. Two common patterns exist.

Host private zones (including privatelink zones) in one connectivity subscription and use Azure Policy to attach private endpoints to those zones. Document the forwarders for on-premises DNS, and remember that peering alone does not share DNS.

Work from the client outward and compare answers from different resolvers.

1. Run nslookup name and note which server answered.
2. Query Azure directly: nslookup name 168.63.129.16 from the VM.
3. Check the VNet DNS servers setting and whether the VM renewed its DHCP lease.
4. Confirm the private zone has the record and the VNet link shows Completed.
5. Verify NSGs, Azure Firewall and routes allow UDP and TCP 53 to custom servers or resolver endpoints.
6. For public zones, query each Azure name server directly and confirm NS delegation at the registrar.
7. Remember caching: wait out the TTL or flush the OS cache.

nslookup app.contoso.com 168.63.129.16
dig app.contoso.com @ns1-01.azure-dns.com +short

Network Watcher connection troubleshoot helps confirm the port 53 path to a custom DNS server.

A dangling record is a DNS entry that still points to an Azure resource name that no longer exists, for example shop.contoso.com CNAME shop-app.azurewebsites.net after the app is deleted.

Because many Azure hostnames (azurewebsites.net, trafficmanager.net, cloudapp.azure.com) can be claimed by anyone, an attacker creates a resource with the same name and now serves content from shop.contoso.com.

The impact is serious: phishing on a trusted domain, cookie theft for the parent domain, and abuse of OAuth redirect URIs. The root cause is deleting the Azure resource without cleaning up the DNS record.

Attackers actively scan for this pattern by listing subdomains of target companies and testing whether the CNAME target is unclaimed. Certificates can even be issued for the hijacked name if validation passes through DNS or HTTP, which makes the phishing page look fully legitimate to users.

Combine process and technical controls.

• Use alias records for Azure resources so the record stays tied to the resource and does not point at a free name.
• Delete DNS records before or together with the resource, and add that step to your decommission checklist or IaC.
• Create the asuid TXT verification record for App Service so another app cannot bind your hostname.
• Use Microsoft Defender for Cloud dangling-DNS detection where available.
• Audit zones regularly for CNAMEs to Azure domains that no longer resolve to your own resources.
• Apply RBAC so only a small team can change DNS.

Treat DNS records as part of the resource lifecycle, ideally deployed and removed by the same pipeline as the app.

A practical routine is to export all CNAME and alias records weekly and test each target. Any CNAME to an Azure domain that returns NXDOMAIN or a default placeholder page should be removed or investigated immediately.

For most new designs, Azure DNS Private Resolver is better because it is managed, but forwarder VMs still make sense in specific cases.

Choose the resolver for forwarding between Azure and on-premises. Keep VM-based servers when you need Active Directory-integrated DNS, DNS policies, or advanced logging not available in the managed service.

Cost is another factor. A resolver charges per endpoint and per query, while VMs add compute, disks and operations time. For small environments with a single on-premises domain, the managed resolver is usually still cheaper once engineering time for patching and HA is counted.

The goal is that every resolver, old or new, gets a working answer throughout the change.

1. Lower TTLs on the records to change (for example 300 seconds), at least one old-TTL period in advance.
2. Make sure the new target is fully ready and tested, with both old and new serving traffic if possible.
3. Test the new records by querying Azure name servers directly.
4. Change the record or the NS delegation.
5. Monitor traffic on both old and new endpoints until old queries stop.
6. Raise the TTL again and decommission the old environment.

For a full provider migration, keep both zones identical and only change the registrar NS records last. NS delegation TTLs at the TLD are often long and outside your control, so plan a long overlap.

Create a Traffic Manager profile with Priority routing and add the primary endpoint first, then the secondary. Health probes watch each endpoint.

1. Create the profile with a short DNS TTL (for example 30-60 seconds) and a probe path such as /health.
2. Add primary (priority 1) and secondary (priority 2) endpoints.
3. In your Azure DNS zone, point app.contoso.com to the profile with a CNAME, or an alias record at the apex.
4. Test failover by stopping the primary and watching the DNS answer change.

Failover time is probe interval times tolerated failures plus the DNS TTL, so it is never instant. Clients that cache DNS beyond the TTL may keep using the failed endpoint.

Test the failover regularly, not just once. A game day where the primary endpoint is stopped confirms probe settings, TTLs and alerting all behave as designed. Also make sure the secondary region has enough capacity to take the full load.

A DNS security policy attaches to virtual networks and controls and logs the DNS queries sent through the Azure resolver.

• Query logging: send DNS query logs to Log Analytics, a storage account or Event Hubs.
• Domain filtering rules: allow, alert or block queries for lists of domains, by priority.
• VNet association: one policy covers all linked VNets.

It helps detect data exfiltration over DNS, connections to malicious domains and unexpected lookups from workloads. Because feature names and regional availability have changed over time, confirm the current status and pricing in the Azure documentation before relying on it.

Start in alert mode before switching rules to block, so you learn which domains workloads really call. Pair the logs with Microsoft Sentinel or Log Analytics queries to spot DNS tunneling patterns such as very long, random-looking subdomains or very high query rates to a single domain.

Azure Policy can make sure private endpoints always register in the right private zone and that unwanted zones are not created.

• Use the built-in DeployIfNotExists policies that create a DNS zone group for private endpoints, pointing to your central privatelink zones.
• Use Deny policies to block the creation of privatelink zones outside the connectivity subscription.
• Use Audit policies to find zones without VNet links or without required tags and locks.
• Assign at management group level so new subscriptions inherit them.

This removes manual DNS steps for application teams and prevents the split-brain situation where each team creates its own duplicate zone with partial records.

Initiatives can bundle the DNS-related policies for each Azure service (blob, SQL, Key Vault and so on) so one assignment covers many private link zones. Remediation tasks then fix existing private endpoints that were created before the policy existed, not only new ones.

Azure DNS pricing is mainly per hosted zone per month plus per million queries, with Private Resolver billed per endpoint hour and per query. Savings come from design choices.

• Use alias records for Azure targets: their queries are free and the answer needs fewer lookups.
• Set sensible TTLs: long enough to cut queries for stable records, short for records that fail over.
• Remove unused zones and test zones.
• Use one central private zone per service type instead of copies per team.
• Avoid chained CNAMEs, which add lookup time.
• Share one Private Resolver per region instead of one per VNet.

Check the Azure pricing page for current rates, as they vary by region and change over time.

Review zone and query charges monthly in Cost Management, tagging zones by team so unused ones are easy to find.

VNet peering connects networks for traffic, not for DNS. A private zone resolves only for VNets that are linked to it or that send queries to a resolver that can see it.

If VM A in VNet 1 can resolve db.corp.internal but VM B in a peered VNet 2 cannot, the zone is probably linked only to VNet 1.

• Add a virtual network link from the zone to VNet 2, or
• Point VNet 2's DNS servers at a custom DNS server or a Private Resolver inbound endpoint in VNet 1, which can resolve the zone.

az network private-dns link vnet create -g rg-dns -n link-spoke2 \
  -z corp.internal -v vnet-spoke2 -e false

Use -e false on the extra link unless you want VMs from that VNet to register records in the zone, and remember only one zone per VNet can have registration.

When a VNet is linked to a private zone whose name matches a domain, the Azure resolver is authoritative for that name inside the VNet. A missing record returns NXDOMAIN, not an answer from the public internet.

This often shows up with split-horizon setups. If contoso.com exists as a private zone and you only added db, then www.contoso.com stops resolving for VMs in linked VNets, though the public zone has it.

• Add the missing records to the private zone.
• Use a different internal domain such as corp.contoso.com to avoid overlap.
• Use the VNet link option for NXDOMAIN fallback to internet resolution where it is available.

Test with nslookup from inside the VNet, since results from a laptop will not show the problem.

Private DNS zones are global resources, so one zone can be linked to VNets in any region. The resolver service, however, is regional.

• Link each private zone to the VNets in every region that needs it, usually the hub VNets and any spokes without a central resolver.
• Deploy a Private Resolver per region so queries stay local and a regional outage does not break DNS elsewhere.
• Give each region's spokes the local resolver (or local hub DNS servers) as their DNS server, with a secondary from the other region if needed.
• For on-premises, create conditional forwarders to the inbound endpoint IPs in both regions.

For auto-registration across regions, use one registration VNet per zone and add regional naming such as eastus.corp.internal so names stay unique and clear.