Microsoft Azure DNS: Public, Private, and Hybrid Design

Azure DNS is not one interchangeable service. A public DNS zone publishes names that internet clients can resolve; Azure Private DNS answers names for linked virtual networks; Azure DNS Private Resolver forwards questions across private network boundaries. Each solves a different part of an application path. An application can have a valid DNS record and still be unreachable because network routing, firewall rules, a private endpoint, or the server itself is wrong.

A sound Azure DNS design starts with who must resolve a name, where that client is located, which address it should receive, and which network path must carry the connection after resolution. Write down those four requirements before creating records. The goal is reliable name resolution that follows the same security and resilience boundaries as the workload.

Use public Azure DNS for internet-facing names

Azure Public DNS hosts authoritative DNS zones for internet domains. It can store common records such as A and AAAA addresses, CNAME aliases, MX mail routes, TXT validation and SPF-related data, and records used for delegation. Hosting a zone in Azure is not the same as buying or registering the domain; the domain registrar must delegate the relevant name servers to the authoritative service.

For a public web application, decide whether the address will remain stable or should follow an Azure resource. An A record points to an IPv4 address; a CNAME names another DNS hostname. At the domain apex, where a conventional CNAME cannot coexist with the zone’s required DNS records, Azure DNS alias records can reference supported Azure resources such as a public IP. This lets a resource address change without manually copying a new IP into the zone record.

Test delegation and the authoritative response separately. When a newly created record does not appear, verify the parent-domain name servers, the actual Azure zone and record, and cached responses before changing the application. A low TTL can help during a planned cutover, but it cannot force every resolver to discard an answer it has already cached.

Use Azure Private DNS for names inside selected networks

An Azure Private DNS zone is for private resolution, not publication to every internet user. Its records become resolvable from Azure virtual networks linked to that zone. A zone can be linked to multiple networks, including networks in different regions, but a zone link is a DNS relationship: it does not create network routing, peering or firewall permission between those networks.

For example, a private application might be named app.internal.example.com and use a private IP in its virtual network. Link the appropriate client virtual networks to the private zone, confirm the record points to the correct interface, and verify that the client has network connectivity to the private address. If name resolution succeeds but TCP connection fails, investigate routing and network security groups rather than repeatedly changing DNS.

Virtual-network links can be resolution-only or support automatic virtual-machine record registration. A registration link causes Azure to maintain supported VM A records as virtual machines are created, change IP or are deleted. An ordinary resolution link allows lookup but does not automatically publish records for its virtual machines. One virtual network can be linked to many private zones for resolution, while automatic registration is limited to one designated registration zone for that network.

Choose the private namespace carefully. Avoid a generic name that collides with public domains or platform behavior. If public and private zones intentionally share a namespace, document the split-horizon answers and test from both inside and outside the relevant virtual networks.

Design Private Endpoint name resolution explicitly

Private Endpoints give supported Azure services a private network interface and address. DNS must return that private address to clients meant to use the endpoint. It is not enough to configure the private endpoint and assume that every connected network or on-premises device will resolve the name correctly.

Microsoft publishes service-specific private DNS zone names, including names in the privatelink namespace for many services. Follow the documented mapping for the exact Azure service and subresource instead of inventing one zone convention for storage, SQL, web apps and every other product. A common design attaches the correct private DNS zone to the networks that require resolution and uses a private DNS zone group to keep endpoint records aligned where supported.

Test with the application’s ordinary service hostname, not only a directly constructed private-link hostname. Confirm the alias chain resolves to the intended private address in the private environment, while other authorized clients receive the behavior the architecture expects. If some clients still resolve a public address, compare the DNS server they use, zone links, conditional forwarding and cached answers before changing the endpoint.

Connect Azure and on-premises DNS with Private Resolver

Hybrid name resolution is where simple Azure DNS diagrams become operationally incomplete. An on-premises client cannot resolve an Azure Private DNS zone just because a VPN or ExpressRoute circuit exists. Azure DNS Private Resolver provides a managed way to connect these namespaces without requiring self-managed Windows or Linux DNS-forwarder virtual machines for every direction.

An inbound endpoint provides an IP address inside the resolver’s Azure virtual network. An on-premises DNS server can use a conditional forwarder to send queries for Azure private names to that inbound endpoint over a working private connection. An outbound endpoint, combined with a DNS forwarding ruleset, can forward selected names from Azure toward on-premises or other custom DNS servers. The two endpoints handle opposite directions and need separate planning.

For example, configure on-premises DNS to forward requests for internal.azure.example.com to the resolver’s inbound endpoint, and configure an Azure forwarding ruleset for corp.example.com that targets on-premises DNS servers via an outbound endpoint. Then verify two distinct tests: a branch workstation resolving the Azure-only hostname, and an Azure VM resolving the on-premises hostname. Passing one test does not prove the other direction is configured.

The resolver endpoints require appropriately sized delegated subnets in the resolver virtual network. Outbound forwarding rulesets are linked to virtual networks that should use those rules. Understand each link and forwarding suffix before deploying: forwarding a broad namespace back toward the inbound resolver can create a loop or route queries to an unintended authority.

Keep DNS resolution and network reachability separate

DNS returns an answer about a name. It does not guarantee that the application is healthy, that the client is authorized, or that the network can reach the returned IP. A public hostname might resolve to a gateway that blocks traffic; a private hostname may resolve perfectly from a client whose virtual network has no route to the service; an application might accept connections but reject requests because identity or TLS trust is wrong.

For every critical service, document the sequence: which resolver the client asks, which zone or forwarding rule answers, what record or alias chain is returned, which IP is selected, which route carries the packet, which security policy applies, and what application response proves success. This makes DNS troubleshooting a bounded step in an end-to-end path investigation rather than a catch-all explanation for any connection failure.

DNS TTLs and resolver caches complicate planned changes. During a cutover, measure what actual clients resolve and consider existing cached answers. If the record has changed but one resolver still returns the old value, investigate cache age and authority. If every resolver returns the new value but the application fails, move to the next layer.

Use record types and aliases according to their purpose

A and AAAA records are address records. CNAME records delegate an alias to another hostname and are generally inappropriate for the zone apex. MX records guide mail routing. TXT records carry verification and other published text. SRV and other specialized record types serve applications with more specific discovery needs. The record type should follow the consumer’s protocol and service requirement rather than whichever choice appears first in the portal.

Azure Public DNS alias record sets can refer to supported Azure resources so a DNS name follows the resource. Ordinary CNAME and alias records are not interchangeable in all contexts, and supported alias target types matter. Before using an alias, verify the Azure resource association and the documented record type. After creating it, test the real resolver response and the application URL, not just the fact that the portal accepted the configuration.

Plan security, ownership and change control

DNS deserves the same operational governance as networking. Public zones can expose services or redirect traffic if records are changed by an unauthorized party; private zones can silently move workloads to the wrong private address if records or zone links are modified without review. Use least-privilege role assignments, separate duties where appropriate, protect domain registrar access, log administrative changes and manage sensitive changes through an approved deployment path.

Public and private visibility is also a design issue. Publishing an internal address or a private service name in a public zone can reveal information or create confusing responses, even if the IP itself is unreachable from outside. Public access to an Azure service should be controlled using its network and identity features, not by hoping the DNS name will remain obscure.

For private endpoints and hybrid DNS, validate both access and denial scenarios. A permitted workload should resolve the intended private name and connect successfully. An unauthorized or incorrectly linked network should not unexpectedly gain a valid path merely because someone added a zone link or a forwarding rule. DNS records, routing and policy must support the same trust boundaries.

Test failure modes before calling the design resilient

A robust design should anticipate a failed custom DNS forwarder, a broken hybrid link, a misconfigured forwarding suffix, conflicting split-horizon zones, and a record pointing to the wrong Azure resource. Each failure has different symptoms. A failed resolver can make many unrelated applications appear unavailable, while one bad record may affect only one service.

Set up a small diagnostic exercise: a public zone for an external test service, a private zone linked to one Azure virtual network, and a mock on-premises namespace reachable through a test forwarder or resolver. Record expected answers from inside and outside Azure. Break one component at a time, document the symptoms, and restore it. Include at least one case in which DNS succeeds but routing fails, so the team learns not to equate name resolution with service availability.

Monitor relevant resolver health, administrative changes and client symptoms. A dashboard showing a green Azure resource does not prove that a user’s local DNS client receives the right response. Query from representative network locations, and preserve the returned answer, its TTL and the next connection test when investigating an incident.

A practical Azure DNS architecture checklist

Before deployment, identify each namespace as public, Azure-private or on-premises; record its authoritative owner and required clients; choose Azure Public DNS, Private DNS, Private Resolver or a deliberate combination; decide whether VM auto-registration is appropriate; map any Private Endpoint to its documented DNS zone; and specify the inbound/outbound forwarding directions for hybrid networks.

Then verify the deployment as a sequence, not a checkbox. Confirm authoritative records and virtual network links, test forward and reverse resolution only where those behaviors are supported, validate TLS names and actual application access, document changes and rollback, and confirm that a failure does not cause unexpected resolution to an unsafe address. Revisit Microsoft’s current Azure DNS and Private Resolver documentation when planning production, because feature support and service quotas can change.

Good Azure DNS architecture is not about creating the most zones or rules. It is about making name resolution predictable across public, private and hybrid boundaries so administrators can explain who receives each answer, why, and which network and security controls must still succeed afterward.