The AZ-700 exam asks you to identify which DNS service fits each scenario. Unlike routing or firewalls, DNS is invisible when it works — but when it breaks, Private Endpoints resolve to public IPs and VMs inside a VNet cannot find internal hostnames at all. Azure addresses this with three pillars: Public Zone, Private DNS Zone, and Private Resolver.
Azure DNS Public Zone: The Public Directory
Think of a city phone book available to anyone who opens it. Azure DNS Public Zone is exactly that — a publicly accessible directory for internet-facing domains like contoso.com, managed entirely within Azure.
When you create a Public Zone, Azure automatically assigns four name servers (in the form ns1-xx.azure-dns.com). You then update the NS records at your domain registrar to point to these four addresses. The sequence matters: you must create the Zone first to learn the NS addresses before you can update the registrar.
Supported record types include A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), and TXT (domain ownership verification). Azure DNS operates using Anycast, distributing queries globally without a single point of failure.
Private DNS Zone: The Internal Directory
Every large office has an internal contact list that never leaves the building — an extension directory. Azure Private DNS Zone manages names that are valid only inside your VNet.
Creating a Private Zone is not enough on its own. You must attach a VNet Link to the Zone before VMs in that VNet can use it for name resolution. There are two link modes.
Auto-registration: When a VM is created in the linked VNet, an A record is automatically registered in the Private Zone. Resolution only: Records are managed manually by administrators; the VNet uses the Zone only for lookups.
A single Private Zone can be linked to multiple VNets, and a single VNet can link to multiple Private Zones. Auto-registration, however, can only be enabled for one Private Zone per VNet.
!Azure DNS Public versus Private Zone
Private Endpoints and the privatelink Domain
Imagine a warehouse with a dedicated staff entrance around the back. Delivery trucks use the main gate, but employees use the private door directly. Azure Private Endpoint is that private door for PaaS services.
When you attach a Private Endpoint to a PaaS service such as Azure Blob Storage or Azure SQL Database, that service becomes reachable via a private IP inside your VNet. However, if you do not update DNS at the same time, clients still send requests to the public IP.
The fix is a Private DNS Zone named . For example, a Storage Account Private Endpoint requires a Zone named , linked to the VNet, with an A record pointing to the Private Endpoint's private IP. When a client inside the VNet queries , CNAME chaining leads it to the Private Zone, which returns the private IP. The Azure portal's 'private DNS integration' toggle automates this Zone creation and A record registration.
Azure DNS Private Resolver: The Corporate Switchboard
Picture the switchboard operator who connects incoming calls to the right desk and also places outgoing calls through the right external line. Azure DNS Private Resolver plays exactly that role between on-premises networks and Azure.
Private Resolver has two endpoint types.
Inbound Endpoint: Provides an IP address inside a VNet that external clients (including on-premises resolvers) can send DNS queries to. When the on-premises DNS server is configured with a conditional forwarder pointing to this IP, on-premises clients can resolve Azure private names. Outbound Endpoint: Forwards DNS queries originating inside Azure to external resolvers, such as on-premises DNS servers. A DNS Forwarding Ruleset defines which domain suffixes go to which upstream resolver.
Before Private Resolver existed, hybrid DNS connectivity required deploying and managing custom DNS virtual machines inside a VNet — Windows Server or BIND. Private Resolver replaces that with a fully managed service.
Split-Horizon DNS
Imagine a building with two entrances: one for the public and one for staff, both labelled with the same address but leading to different receptions. Split-horizon DNS is the same idea — the same domain name returns different IP addresses depending on where the query originates.
For example, resolves to a public IP for internet clients (via the Public Zone) and to a private IP for VMs inside a VNet (via a Private Zone with the same name). To configure this, you create both a Public Zone and a Private Zone for , then link the Private Zone to the relevant VNet. Azure prioritises the Private Zone for queries originating inside the VNet.
This pattern appears frequently when a service needs to be reachable from both the internet and internal networks, or when Private Endpoints and public endpoints coexist for the same service.
Comparison: Which DNS Approach to Choose
| Scenario | Solution | |:--|:--| | Manage an internet-facing domain | Azure DNS Public Zone | | Internal name resolution inside a VNet | Private DNS Zone + VNet Link | | PaaS Private Endpoint name resolution | privatelink.{service} Private Zone | | On-premises → Azure private names | Private Resolver Inbound Endpoint | | Azure → on-premises DNS forwarding | Private Resolver Outbound Endpoint + Ruleset | | Same name, different IPs inside vs outside | Split-horizon (Public + Private Zone coexist) | | Default VNet name resolution | Azure-provided DNS (168.63.129.16) |
Azure-provided DNS at 168.63.129.16 is the default resolver for every VNet. If you configure a custom DNS server at the VNet level, that server must forward to 168.63.129.16 as a conditional forwarder for Azure internal names to continue resolving correctly.
Common Pitfall: When Private Endpoint Still Resolves to a Public IP
A new engineer creates a Private Endpoint and immediately opens a ticket: 'connection refused.' The root cause is almost always DNS. Creating the Private Endpoint is only half the work — if DNS still points to the public IP, clients bypass the private network path entirely.
Work through this checklist.
Does the Private Zone exist? Is that Zone linked to the client VNet? Does the Zone contain an A record pointing to the Private Endpoint's private IP? Is the client VNet using Azure-provided DNS (168.63.129.16), or does its custom DNS server forward Azure names to 168.63.129.16?
For on-premises clients, the on-premises DNS server must also have a conditional forwarder for the domain suffix, pointing to the Private Resolver Inbound Endpoint IP.
Exam Key Takeaways
Internet-facing domain, Azure NS delegation -- Azure DNS Public Zone Internal VNet names, automatic VM registration -- Private DNS Zone + VNet Link (Auto-registration) PaaS Private Endpoint name resolution -- privatelink.{service} Private Zone + A record On-premises → Azure internal names -- Private Resolver Inbound Endpoint Azure → on-premises DNS forwarding -- Private Resolver Outbound Endpoint + Forwarding Ruleset Same name, different IPs inside vs outside -- Split-horizon (Public Zone + Private Zone coexist) Default VNet DNS address -- 168.63.129.16 (Azure-provided DNS) Auto-registration limit -- only one Private Zone per VNet can have it enabled Custom DNS + Private Zone together -- custom DNS must forward to 168.63.129.16 Top reason Private Endpoint fails to connect -- missing DNS config (no Private Zone or no VNet Link)
Azure DNS = public directory, Private DNS Zone = internal directory, Private Resolver = corporate switchboard