Loading...

Centralized private resolver architecture implementation using Azure private DNS resolver

Centralized private resolver architecture implementation using Azure private DNS resolver

This article walks you through the steps to setup a centralized architecture to resolve DNS names, including private DNS zones across your Azure network and on-premises DNS using an Azure DNS private Resolver in a hub and spoke VNet topology.

 

Architecture diagram:

Sanjeev_Kumar1945_0-1715018350133.png

 

In the above architecture:

  • Two VNets are created: “HUB-VNET” and “SPOKE-VNET”.
  • An Azure DNS private resolver is created in the HUB-VNET with inbound endpoint at (10.0.0.4)
  • A DNS forwarding ruleset is created for the private resolver “myruleset”.
  • The DNS forwarding ruleset is linked to the HUB-VNET.
  • Rules are added to the DNS forwarding ruleset for the on-premises DNS server.
  • HUB-VNET is linked to all the Azure private DNS zones with Virtual network link.
  • On-premises network is simulated as a third VNet and is peered to the HUB-VNET.
  • ExpressRoute, Azure Firewall and ExpressRoute gateway are representational. On-prem to Azure connectivity could be a mix & match of ExpressRoute and Site-to-Site.
  • A conditional forwarder is created in the on-premises DNS server for the private DNS zones configured on Azure to inbound endpoint at (10.0.0.4).

Create Azure Hub virtual network:

Create HUB-VNET with address space 10.0.0.0/24 and two subnets.

  • Subnet name: snet-inbound
  • Subnet address range: 10.0.0.0/28
  • Subnet name: snet-outbound
  • Subnet address range: 10.0.0.16/28

Sanjeev_Kumar1945_1-1715018436459.png

 

Create a DNS resolver inside the Azure HUB virtual network:

  • Create DNS private resolver in “HUB-VNET” with a DNS forwarding ruleset “myruleset”

Sanjeev_Kumar1945_6-1715018600750.png

 

DNS forwarding ruleset “myruleset” is created and linked to the HUB-VNET during the DNS private resolver creation. In this example there is only one rule in the ruleset.

  • Rule Name: onprem-contosocom
  • Domain name: contoso.com
  • Destination IP: port: 192.168.0.4:53 (On-premises DNS server)

Sanjeev_Kumar1945_7-1715018655236.png

 

  • Add a Virtual network link for HUB-VNET with Azure private DNS “privatelink.blob.core.windows.net”

Sanjeev_Kumar1945_8-1715018694096.png

 

Create Azure spoke virtual network:

Create SPOKE-VNET with address space 10.0.1.0/24 and one subnet.

  • Subnet name: app-subnet
  • Subnet address range: 10.0.1.0/26

Sanjeev_Kumar1945_9-1715018713112.png

 

  • Create a peering connection between SPOKE-VNET and HUB-VNET.
  • Specify the inbound endpoint IP address of the DNS private resolver (10.0.0.4) as the custom DNS server for SPOKE-VNET.

Create a conditional forwarder:

 On-premise DNS server conditional forwarder

  • DNS Domain: blob.core.windows.net
  • Forwarder: 10.0.0.4

Sanjeev_Kumar1945_10-1715018730710.png

 

Test the DNS resolution

Now you should be able to send resolve DNS from Azure to on-premise as well as on-premise to Azure.

DNS resolution On-Premises:

  • On-premise client query’s on-premise DNS server (192.168.0.4).
  • On-premise DNS name is resolved by the on-prem DNS server
  • For Azure private DNS conditional forwarder is used. On-premise DNS server forwards the DNS request to Azure private DNS resolver inbound endpoint (10.0.0.4).
  • Azure private DNS resolver uses the outbound endpoint to query Azure DNS (168.63.129.16) and resolves the DNS query for “myblobdnsdemo.blob.core.windows.net.” to (192.168.2.78)

Sanjeev_Kumar1945_11-1715018755423.png

 

DNS resolution in the hub VNet:

  • The virtual network link from the private zone to the Hub VNet enables resources inside the hub VNet to automatically resolve DNS records in privatelink.blob.core.windows.net using Azure-provided DNS (168.63.129.16).
  • Based on the ruleset “myruleset”, DNS resolution for contoso.com is forwarded and resolved through on-premise DNS server (192.168.0.4).
  • All the namespaces which are not matching the ruleset rule are resolved without forwarding using Azure-provided DNS. E.g. public DNS names.

Sanjeev_Kumar1945_12-1715018773363.png

 

DNS resolution in the spoke VNet:

  • The spoke VNet uses custom DNS and sends all of its DNS traffic to the inbound endpoint in the Hub VNet.
  • Since “privatelink.blob.core.windows.net” has a virtual network link to the Hub VNet, all resources in the Hub can resolve “privatelink.blob.core.windows.net”, including the inbound endpoint (10.0.0.4). So, the spoke uses the hub inbound to resolve the private zone.
  • Contoso.com DNS names is resolved for the spoke VNet through (192.168.0.4) according to rules provisioned in a forwarding ruleset.

Sanjeev_Kumar1945_13-1715018790215.png

 

Conclusion: Azure private DNS resolver helps implement a private resolver architecture without worrying about maintaining your own DNS server.

One can implement a centralized private resolver architecture as shown above example or can implement a distributed DNS architecture. In case of a distributed DNS architecture, the DNS forwarding ruleset is linked to the spoke VNet with a ruleset rule configured to forward queries for the private zone to the inbound endpoint (10.0.0.4) of the private DNS resolver deployed in the hub VNet and another rule to forward queries for contoso.com to on-premise DNS server (192.168.0.4)

 

DNS resolution in the hub VNet does not require a ruleset for private zones as it can resolve privatelink.blob.core.windows.net using Azure-provided DNS (168.63.129.16). It requires a ruleset to forward queries for contoso.com as shown in the above example “myruleset” rule “onprem-contosocom”.

 

Important: Hub VNet linked ruleset must not be linked to a forwarder ruleset with an inbound endpoint forwarding rule because this configuration can cause a DNS resolution loop.

 

Next Steps:

 

 

Published on:

Learn more
Azure Infrastructure Blog articles
Azure Infrastructure Blog articles

Azure Infrastructure Blog articles

Share post:

Related posts

General Availability of SQL FCI and AG Features SQL Server Enabled by Azure Arc

We have good news. Two business continuity features for SQL Server enabled by Azure Arc are now generally available: View Failover Cluster In...

1 day ago

Azure VMware Solution using a public IP down to the NSX-T Edge; configure SNAT, No-SNAT & DNAT

Azure VMware Solution How To Series: Configuring NSX-T SNAT, No-SNAT & DNAT rules   Overview Requirements Lab Environment NAT Rules K...

1 day ago

App attach for Azure Virtual Desktop now generally available

App attach for Azure Virtual Desktop allows IT admins to dynamically attach applications from an application package to a user session in Azur...

2 days ago

A Closer Look at Azure WAF’s Data Masking Capabilities for Azure Front Door

The Azure Web Application Firewall (WAF) on Azure Front Door offers centralized protection for your web applications against vulnerabilities a...

2 days ago

Azure Virtual Network Manager (AVNM) Mesh and Direct Connectivity are Generally Available!

Azure Virtual Network Manager's (AVNM) mesh connectivity configuration and direct connectivity option in the hub and spoke connectivity config...

2 days ago

Azure pricing: How to calculate costs of Azure products and services

In our previous blogs we explained the Azure pricing structure and how customers can estimate their project costs when migrating to Azure or b...

2 days ago

Azure Pricing: How to estimate Azure project costs

In the previous blog we explained how you can learn about Azure pricing with free services and a pay-as-you-go model. Next, lets understand ho...

2 days ago

Azure Pricing: How to navigate Azure pricing options and resources

In this blog we discussed customer pricing needs and how they match different phases of the cloud journey, and we provided various tools and r...

2 days ago

Azure pricing: How to optimize costs for your Azure workloads

In our previous blogs we explained the Azure pricing structure, how customers can calculate their costs when migrating or building in Azure, a...

2 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy