In this blog post, we’ll demystify the various DNS components available in Azure - such as Private DNS Zones, DNS Private Resolvers, DNS Forwarding Rulesets, and Conditional Forwarders and explain how they fit into a well-architected landing zone. There is often confusion around what custom DNS settings virtual networks should use: should they point to on-premises domain controllers, to Azure DNS Private Resolvers endpoints? we'll walk through common design patterns and provide guidance on how to structure DNS in a scalable and secure way for enterprise-grade Azure deployments.
Why DNS architecture matters in Landing Zone
A well-designed DNS layer is the glue that lets workloads in disparate subscriptions discover one another quickly and securely. Getting it right during your Azure Landing Zone rollout avoids painful refactoring later, especially once you start enforcing Zero-Trust and hub-and-spoke network patterns.
Typical Landing-Zone topology
|
Subscription |
Typical Role |
Key Resources |
|
Connectivity (Hub) |
Transit, routing, shared security |
Hub VNet, Azure Firewall / NVA, VPN/ER gateways, Private DNS Resolver |
|
Security |
Security tooling & SOC |
Sentinel, Defender, Key Vault (HSM) |
|
Shared Services |
Org-wide shared apps |
ADO and Agents, Automation |
|
Management |
Ops & governance |
Log Analytics, backup etc |
|
Identity |
Directory and auth services |
Extended domain controllers, Azure AD DS |
All five subscriptions contain a single VNet. Spokes (Security, Shared, Management, Identity) are peered to the Connectivity VNet, forming the classic hub-and-spoke.
Centralized DNS with mandatory firewall inspection
Objective: All network communication from a spoke must cross the firewall in the hub including DNS communication.
|
Design Element |
Best-Practice Configuration |
|
Private DNS Zones |
Link only to the Connectivity VNet. Spokes have no direct zone links. |
|
Private DNS Resolver |
Deploy inbound + outbound endpoints in the Connectivity VNet. Link connectivity virtual network to outbound resolver endpoint. |
|
Spoke DNS Settings |
Set custom DNS servers on each spoke VNet equal to the inbound endpoint’s IPs. |
|
Forwarding Ruleset |
Create a ruleset, associate it with the outbound endpoint, and add forwarders: • Specific domains → on-prem / external servers • Wildcard “.” → on-prem DNS (for compliance scenarios) |
|
Firewall Rules |
Allow UDP/TCP 53 from spokes to Resolver-inbound, and from Resolver-outbound to target DNS servers |
Note:
Azure private DNS zone is a global resource. Meaning single private DNS zone can be utilized to resolve DNS query for resources deployed in multiple regions.
DNS private resolver is a regional resource. Meaning it can only link to virtual network within the same region.
Traffic flow
- Spoke VM → Inbound endpoint (hub)
- Firewall receives the packet based on spoke UDR configuration and processes the packet before it sent to inbound endpoint IP.
- Resolver applies forwarding rules on unresolved DNS queries; unresolved queries leave via Outbound endpoint.
DNS forwarding rulesets provide a way to route queries for specific DNS namespaces to designated custom DNS servers.
Fallback to internet and NXDOMAIN redirect
Azure Private DNS now supports two powerful features to enhance name resolution flexibility in hybrid and multi-tenant environments:
Fallback to internet
Purpose: Allows Azure to resolve DNS queries using public DNS if no matching record is found in the private DNS zone.
Use case: Ideal when your private DNS zone doesn't contain all possible hostnames (e.g., partial zone coverage or phased migrations).
How to enable:
Go to Azure private DNS zones -> Select zone -> Virtual network link -> Edit option
Ref article: https://learn.microsoft.com/en-us/azure/dns/private-dns-fallback
Centralized DNS - when firewall inspection isn’t required
Objective: DNS query is not monitored via firewall and DNS query can be bypassed from firewall.
- Link every spoke virtual directly to the required Private DNS Zones so that spoken can resolve PaaS resources directly.
- Keep a single Private DNS Resolver (optional) for on-prem name resolution; spokes can reach its inbound endpoint privately or via VNet peering.
- Spoke-level custom DNS This can point to extended domain controllers placed within identity virtual.
This pattern reduces latency and cost but still centralizes zone management.
Integrating on-premises active directory DNS
Create conditional forwarders on each Domain Controller for every Private DNS Zone pointing it to DNS private resolver inbound endpoint IP Address.
(e.g.,blob.core.windows.net database.windows.net). Do not include the literal privatelink label.
Note:
Avoid selecting the option “Store this conditional forwarder in Active Directory and replicate as follows” in environments with multiple Azure subscriptions and domain controllers deployed across different Azure environments.
Key takeaways
- Linking zones exclusively to the connectivity subscription's virtual network keeps firewall inspection and egress control simple.
- Private DNS Resolver plus forwarding rulesets let you shape hybrid name resolution without custom appliances.
- When no inspection is needed, direct zone links to spokes cut hops and complexity.
- For on-prem AD DNS, the conditional forwarder is required pointing it to inbound endpoint IP, exclude privatelink name when creating conditional forwarder, and do not replicate conditional forwarder Zone with AD replication if customer has footprint in multiple Azure tenants.
- Plan your DNS early, bake it into your infrastructure-as-code, and your landing zone will scale cleanly no matter how many spokes join the hub tomorrow.
Microsoft
