Welcome to the final lesson in our module on Azure's core networking infrastructure. In our last session, we established the physical and logical "highways" between your on-premises datacenter and Azure by comparing VPN Gateways and ExpressRoute. Having built these connections, we now face the crucial task of creating a unified "address book" so that services on both sides of the hybrid divide can find and communicate with each other.
This lesson directly addresses that challenge. Our goal is to evaluate DNS resolution strategies for hybrid environments. You'll learn how Azure enables seamless, bi-directional name resolution, allowing on-premises servers to resolve Azure private services and Azure workloads to resolve on-premises resources. We will contrast the traditional, VM-based approach with the modern, managed service, Azure DNS Private Resolver, providing you with the architectural framework needed to design a robust and maintainable hybrid DNS solution.
The Hybrid DNS Problem
In a cloud-only environment, Azure DNS works almost magically. When you link an Azure Private DNS Zone (like the one created for a Private Endpoint) to a virtual network, any VM in that VNet can resolve the private IP address. However, this magic relies on a special IP address, 168.63.129.16, which is only reachable from within Azure.
This creates two fundamental problems in a hybrid scenario:
- On-premises to Azure: Your on-premises DNS servers cannot forward queries to
168.63.129.16. This means they can't resolve names in your Azure Private DNS Zones, such as theprivatelinkrecords for PaaS services secured with Private Link. - Azure to On-premises: The default Azure DNS has no knowledge of your internal, on-premises domain names (e.g.,
app.corp.internal). There is no native way to tell Azure DNS to forward these specific queries to your on-premises DNS servers.
The video below from John Savill provides an excellent overview of these historical challenges.
Azure DNS Private Resolver Deep Dive
This video, "Azure DNS Private Resolver Deep Dive," sets the stage by explaining the core problems that the service is designed to solve.
Watch the introduction from the beginning. Focus on the explanation of why on-premises DNS can't resolve Azure private zones and why Azure DNS can't forward to on-premises DNS servers. This clearly defines the problem space we're about to solve.
The Historical Solution: DNS Forwarder VMs
Before Azure introduced a managed service, the standard architectural pattern was to deploy one or more IaaS virtual machines in Azure to act as DNS forwarders.
The logic was as follows:
- An on-premises DNS server would be configured with a conditional forwarder. For any query ending in
.core.windows.net, for example, it would forward the request to the private IP of the DNS forwarder VM in Azure. - The DNS forwarder VM, sitting inside an Azure VNet, can reach the magic
168.63.129.16address. It takes the request from on-premises and forwards it to Azure's internal DNS, which then resolves the private endpoint's IP address.
This pattern works, but it reintroduces the exact IaaS management overhead that PaaS services aim to eliminate. You are responsible for patching, securing, scaling, and ensuring high availability for these critical DNS forwarder VMs.
Azure DNS Private Resolver - Azure Architecture Center
This document from the Azure Architecture Center clearly contrasts the old and new methods.
Read the section titled Use a DNS forwarder VM. This will give you a solid understanding of the previous best practice and its associated workflow, which is crucial context for appreciating the value of the Private Resolver.
The Modern Solution: Azure DNS Private Resolver
Azure DNS Private Resolver is a PaaS service designed to replace the DNS forwarder VM pattern entirely. It provides a highly available, scalable, and fully managed solution for hybrid DNS. It's composed of two main, independent components: inbound endpoints and outbound endpoints.
1. Inbound Endpoints: Resolving Azure Resources from On-Premises
An inbound endpoint is a network interface with a private IP address from a dedicated subnet within your VNet. Its sole purpose is to listen for DNS queries coming from outside the VNet (e.g., from your on-premises DNS servers).
Instead of forwarding queries to a self-managed VM, your on-premises DNS server's conditional forwarder now points to the IP address of the Private Resolver's inbound endpoint. The Private Resolver handles the rest, forwarding the query to Azure DNS. This elegantly solves the on-prem-to-Azure resolution problem without any IaaS overhead.
Azure DNS Private Resolver Deep Dive
John Savill's video continues by explaining how inbound endpoints work.
Watch the segment from his explanation of the inbound endpoint. He clearly lays out how this single component replaces the need for a custom DNS forwarder VM, simplifying the architecture significantly.
2. Outbound Endpoints & Rule Sets: Resolving On-Premises Resources from Azure
The second half of the problem is enabling Azure resources to resolve internal on-premises names. This is solved by combining an outbound endpoint with a DNS forwarding rule set.
- An outbound endpoint is also a network interface with a private IP from a dedicated subnet. It acts as the source for DNS queries that need to be sent from Azure to your on-premises DNS servers.
- A DNS forwarding rule set is a collection of rules you define. Each rule maps a specific domain name (e.g.,
corp.internal) to the IP address(es) of your on-premises DNS servers. - You then link this rule set to your virtual networks.
When a VM in a linked VNet makes a DNS query, Azure DNS checks the rule set. If the query matches a rule (e.g., for server.corp.internal), the Private Resolver uses its outbound endpoint to forward the query to your on-premises DNS server. For any other query, standard Azure DNS resolution applies.
Azure DNS Private Resolver Deep Dive
The next part of the video covers the outbound flow.
Continue watching from the explanation of outbound endpoints and rule sets. Pay close attention to how the rule set is linked to a VNet and how the outbound endpoint provides the necessary IP connectivity to query the on-premises DNS servers.
Putting It All Together: Architectural Patterns
The most common implementation of this is within a hub-spoke network topology, where the DNS Private Resolver is deployed into the central hub VNet. Let's walk through the end-to-end flows in this architecture.
This Microsoft Learn reference architecture provides a comprehensive blueprint for a hybrid DNS solution.
First, quickly review the introduction and architecture diagram to get a high-level view. Then, carefully study the two workflow sections: Azure to on-premises and On-premises to Azure. These sections trace the step-by-step query paths for both directions, solidifying your understanding of how the components interact.
A key architectural decision when using rule sets in a hub-spoke model is how to configure DNS for the spoke VNets.
- Centralized Model: You can change the DNS server settings on each spoke VNet to point directly to the private IP of the Private Resolver's inbound endpoint in the hub. This forces all DNS traffic from the spokes through the resolver, giving you a central point of control and logging.
- Distributed Model: You can leave the spoke VNets using the default Azure DNS and simply link the forwarding rule set to each spoke. In this model, only queries that match a rule in the set are handled by the resolver; all other queries (for public domains or other Azure services) are handled directly by Azure DNS, which can be slightly more efficient.
For a Principal Engineer, understanding this trade-off between centralized control and distributed efficiency is key.
Key Considerations
When designing your hybrid DNS strategy, keep the following points in mind:
- Split-Brain DNS: This is a pattern where a single FQDN resolves to different IP addresses depending on whether it's queried from an internal or external network. Private Endpoints are a perfect example:
mystorage.blob.core.windows.netresolves to a public IP on the internet but a private IP within your VNet. The Private Resolver is the mechanism that enables this pattern to extend seamlessly to your on-premises network. - High Availability: DNS Private Resolver is a managed service with built-in availability. The inbound and outbound endpoints are inherently resilient within an Azure region. For cross-region resiliency, you would deploy a Private Resolver in each region.
- Cost: The service is billed based on the number of endpoints and the volume of queries processed. While not free, it is typically more cost-effective than deploying, managing, and scaling a custom IaaS solution, especially when total cost of ownership is considered.
Conclusion
In this lesson, we dissected the complexities of hybrid DNS and evaluated Azure's modern solution. You are now equipped to design a name resolution strategy that bridges the gap between your on-premises and cloud environments.
Here are the essential takeaways:
- The Problem: Standard Azure DNS and on-premises DNS cannot resolve each other's private zones without a specialized solution.
- The Old Way: Using IaaS VMs as DNS forwarders works but carries significant management overhead.
- The New Way (Azure DNS Private Resolver): A managed PaaS service that solves the problem elegantly.
- Inbound Endpoints allow on-premises systems to resolve Azure private zones.
- Outbound Endpoints & Rule Sets allow Azure systems to resolve on-premises zones.
- Architecture: The Private Resolver fits perfectly into a hub-spoke topology, creating a centralized and manageable DNS gateway for your entire hybrid environment.
This lesson concludes our module on Azure Networking. You've progressed from the basic building blocks of VNets and subnets to sophisticated hybrid connectivity and name resolution strategies. In our next module, we will shift our focus from the network foundation to the workloads that run upon it, starting with a deep dive into Azure Compute Services.