Azure DNS Private Resolver is a first-party Azure managed network component that facilitates DNS name resolution integration between On-premises to Azure and vice-versa.

Historically, on Azure cloud customers needed to rely on Infrastructure-as-a-Service (IaaS) solutions, configuring virtual machines either as DNS forwarders or Network Virtual Appliances (NVA) to achieve correct name resolution across their on-premises environments and Azure. These setups were not only complex but also introduced potential single points of failure, diminishing the network's overall resilience and efficiency.

Recently I have encountered scenarios where customers expressed a desire to transition away from these IaaS-based DNS forwarders. Their goal was clear: to eliminate these single points of failure and significantly boost their network's resiliency, especially in disaster recovery (DR) scenarios. They envisioned an active-active DR solution where, even in the event of a DNS service outage in the primary region, their organization's name resolution would continue uninterrupted. Moreover, they expected name resolution to be handled by their regional Azure Private DNS (Az PDNS) service by default, only routing to another region if the primary was compromised.
Here is Architecture design for Prod/DR in Active Scenario

To fulfill these requirements, I have devised an architectural design tailored for production and DR in an active-active configuration. This design necessitates several critical adjustments:

1. DNS Resolver Service Configuration: Each DNS resolver service in every region must be capable of resolving the names (URLs) of all workloads.

2. Private DNS Zone Linking: As Platform-as-a-Service (PaaS) resources have separate instances running in both regions, their respective private DNS zones should be linked to the Virtual Network (VNet) of the PDNS resolver service.

3. Conditional Forwarder Zones: Production and DR Active Directory (AD) DNS servers must be set up with non-AD integrated conditional forwarder zones for Azure workloads (e.g., Blob storage, Az SQL.), enabling private access through the on-premises network.

4. Configuration of Conditional Forwarders: The conditional forwarder zones in Prod and DR AD-DNS servers must have a different sequence of primary and secondary endpoints. This ensures that DNS traffic from each environment or region is managed by its respective DNS resolver service, addressing the customer's need for regional traffic management and eliminating cross-region dependencies during DR scenarios.

Here is screenshot of conditional forwarders config & name resolution details.

Name Resolution from on-premises against Blob storage private endpoint.

Private DNS zone details for blob storage on azure

This architecture pattern not only signifies improvement in DNS management but also reflects in more resilient, efficient, and scalable overall azure infrastructure which complement each other in active-active DR scenarios.

Thanks for reading!

Do you have any other tips to improve my blog? Let me know in the comments, or just say hi 👋.

Until next time, Happy Learning