Microsoft AZ-700: Azure DNS & Name Resolution — Study Guide

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Part of the Microsoft Azure Network Engineer AZ-700 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Azure DNS: public zones, private zones, and trade-offs

Azure provides both public DNS hosting and private DNS resolution tightly integrated with the virtual network plane, and choosing between them is a matter of scope, control, cost, and operational overhead. Public Azure DNS zones (hosted in Azure DNS) are appropriate for internet-facing names and benefit from global anycast endpoints, predictable API-driven management, and per-query scale. Private DNS zones let you authorate zone names that only resolve to private IP addresses inside linked VNets; they eliminate the need to run and maintain DNS VMs for intra-Azure name resolution and support automatic record management when integrated with certain PaaS private endpoints. The main trade-off is control: custom DNS servers (Windows DNS, BIND) give absolute flexibility—conditional forwarding, advanced policies, and AD-integrated SRV/CNAME behavior—at the cost of VM/management overhead and resilience responsibility. Performance choices come down to latency vs. cost: managed Azure DNS services reduce maintenance and provide global resolution speed for public queries, while hub-resident DNS forwarders or resolver appliances can improve hybrid performance and enforce policies but add compute and availability cost. Common traps include forgetting to link a Private DNS zone to every VNet that needs resolution, failing to migrate delegations when moving names from on-prem to Azure, and expecting automatic public-to-private split-horizon behavior without explicit DNS records or forwarding.

Azure DNS (Public): global anycast, managed API, per-zone/query billing.
Private DNS zones: VNet-scoped resolution, automatic private record creation for supported PaaS.
App Gateway WAF_v2: recommended for modern WAF features and v2 scaling model.
Azure Firewall (Standard/Policy): central DNS proxy option; adds cost but centralizes policy.
Custom DNS (VM-based): maximum control, higher Ops and availability costs.

Private DNS zones, private endpoint records, and naming strategies

When you convert publicly hosted services to private endpoints or migrate servers into Azure, DNS becomes the coordination point. Private endpoints register NIC-level A records in private DNS zones that must match the public FQDN you want clients to use; the correct pattern is to create private zones that mirror the public namespace (for example, contoso.com) or use service-specific privatelink zones (for platform services) and then either enable automatic registration or create manual A/CNAME records mapping the FQDN to the endpoint private IP. Scope matters: linking a private zone to a single VNet limits resolution to that VNet; hub-and-spoke designs require linking the zone to all spokes or using DNS forwarding from spokes to a hub resolver. A typical migration trap is leaving public DNS pointing to the old on-prem IP while Azure clients resolve to a private IP; to avoid split-brain confusion, plan clean cutover steps—update public records only after private DNS and forwarding are validated, or use split-horizon naming with an explicit private zone for the same name. Certificates and host headers must align: if you expect Application Gateway to perform end-to-end TLS to a private backend, ensure the backend certificate CN/SAN matches the hostname that the gateway sends as the Host header; otherwise backend TLS will fail.

Azure Private Resolver and hybrid name resolution patterns

Azure Private Resolver enables managed, scalable DNS forwarding between Azure VNets and on-premises networks without owning DNS VMs. Design patterns typically place resolver endpoints in a hub VNet: inbound endpoints receive queries from on-prem (via VPN/ExpressRoute) for Azure private zones, while outbound endpoints forward Azure queries to on-prem DNS servers for internal-only names. Resolver rule sets define conditional forwarding for specific namespaces (for example, contoso.internal → on-prem DNS IPs) and can be associated with vNets; for global enterprise deployments you centralize rule management in the hub and peer or route traffic from spokes to the hub resolver. Performance vs cost trade-offs include provisioning multiple inbound endpoints across regions for resilience and latency (adding cost) or accepting single-region resolver endpoints with peering but higher cross-region latency. Common pitfalls: not updating on-prem conditional forwarders to point to resolver inbound IPs, misconfiguring network security group rules that block DNS TCP/UDP 53 to resolver endpoints, and assuming Azure-provided DNS (168.63.129.16) will forward to on-prem—explicit resolver configuration is required for conditional forwarding.

DNS ports: 53 UDP and 53 TCP must be allowed for typical resolution and zone transfers.
Resolver endpoints: deploy in hub VNets; ensure NSG and firewall allow inbound DNS.

Custom DNS servers, DNS proxying, and operational traps

Custom DNS servers (Windows DNS domain controllers or Linux BIND) still make sense when Active Directory integration, complex conditional forwarding, or advanced DNS policies are required; however, they introduce operational responsibilities—patching, HA clustering, backups, and scaling. Alternatives that reduce Ops are Azure Private DNS zones for intra-Azure resolution and Azure Private Resolver or Azure Firewall DNS proxy to centralize forwarding policies. DNS proxies (Azure Firewall DNS proxy feature or third-party NVAs) can intercept and forward DNS to selected resolvers, which simplifies policy and logging but can add single points of failure and additional latency. Key design decisions include whether to use VM-based forwarders in a hub (lower cost, higher maintenance) versus Azure Private Resolver (managed, better scale), how many resolver endpoints to deploy across regions for latency/resilience, and whether to enable automatic private endpoint DNS registration. Frequent engineer mistakes are relying on VNet peering alone for DNS resolution (peering doesn’t automatically share Private DNS zones), forgetting to grant the Private Endpoint permission to auto-register DNS records, and neglecting to validate certificate chains when implementing end-to-end TLS through a gateway—these all break name resolution or secure connections in production.

Practical Problem: Use-Case Scenario

Scenario: Fabrikam Inc. operates a multi-region hub-and-spoke Azure network. The hub in East US contains Azure Firewall (Standard) and a Traffic Manager profile routes internet users to Application Gateway WAF_v2 instances in two regions. Two App Service instances host www.fabrikam.com, each moved from on-prem with private endpoints in their regional spokes.

Challenge: On-prem clients and Azure spokes must resolve www.fabrikam.com to the App Service private endpoints after migration, Application Gateway must preserve host headers to enable end-to-end TLS, and DNS resolution must be resilient across regions.

Recommended Approach:

Deploy an Azure Private DNS zone named fabrikam.com in the hub and link it to both regional spoke VNets and the hub VNet; add A records for www.fabrikam.com pointing to the private endpoint IPs (or enable auto-registration for the App Service private endpoints).
Deploy Azure Private Resolver inbound endpoints in the hub (one per region for resiliency if needed) and configure on-prem conditional forwarders to forward fabrikam.com queries to the resolver inbound IPs.
Configure Application Gateway WAF_v2 HTTP settings to use HTTPS on port 443, set the backend host header to www.fabrikam.com, and ensure backend health probes use HTTPS with a host header matching the certificate CN/SAN.
Validate by running DNS queries from on-prem and from spokes to ensure they return private IPs, and verify Application Gateway end-to-end TLS by checking certificate CN/SAN and probe success.

Rationale: Centralizing private DNS and resolver functionality in the hub provides single-source truth and simplifies hybrid conditional forwarding; linking the private zone to all VNets and ensuring the gateway uses the correct host header preserves certificate validation for end-to-end TLS, balancing operational manageability, performance, and resilience.

← Hybrid Networking · All domains · Network Security →

Practice these questions → · Timed practice on ExamRoll.io →