Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Deploy a Hybrid DNS infrastructure with DNS Private Resolver

  • February 23, 2023
  • 7 min read
IT and Virtualization Consultant. Romain is specializing in Microsoft technologies such as Hyper-V, System Center, storage, networking, and MS Azure. He is a Microsoft MVP and MCSE in Server Infrastructure and Private Cloud.
IT and Virtualization Consultant. Romain is specializing in Microsoft technologies such as Hyper-V, System Center, storage, networking, and MS Azure. He is a Microsoft MVP and MCSE in Server Infrastructure and Private Cloud.


When you deploy a service in Microsoft Azure that requires to be reachable only with private IP address, you need a private endpoint. Most of the time, the IP address of this private endpoint must be resolvable through a private DNS.

A private DNS is a zone that is linked to a virtual network and only services that belong to this virtual network can resolve name through this private DNS zone. That means that On-Premises VMs cannot resolve name inside a private DNS zone. In addition, services in the virtual network that is linked to a private DNS zone cannot resolve On-Premises name.

To solve this issue, we can use a DNS Private Resolver. Thanks to DNS Private Resolver we can forward DNS request to another DNS server. DNS Private Resolver also provides an IP address that can be used by external DNS server to forward requests. So external On-Premises DNS servers will be able to resolve name located in a private DNS zone.

Private DNS zone configuration

I have the following private DNS zones. They come from the configuration of a storage account and Azure Virtual Desktop with private endpoint.

Private DNS zones

Each private DNS zone has two links:

  • Link-dns-hub: this is a link to a hub virtual network where is located the private resolver
  • Link-dns-xxx: this is a link to a spoke virtual network where are located my services that require to resolve name from the private dns zone.

Each private DNS zone has two links

DNS Private Resolver configuration: Inbound requests

After the DNS private resolver deployment, you should get something like that. DNS Private resolver requires at least two subnets:

  • A subnet for inbound endpoint: an IP is allocated to this subnet to allow DNS servers to forward request to DNS private resolver
  • A subnet for outbound endpoint: this subnet is used to forward requests to DNS servers and then provide the resolution to services that initiate the resolution.

DNS Private resolver requires at least two subnets

If you navigate to Inbound endpoints, you can create a private IP address. This IP address is used in DNS configuration for conditional forwarders.

Inbound endpoints

In my On-Premises domain controller, I have created a conditional forwarder for each private DNS zone. Then a specified the above IP address as master servers. So, each time someone will try to resolve the name in these DNS zone, the requests will be forwarded to DNS Private resolver in Azure.

N.B: In this kind of scenario, a connection to Azure is required (such as Express Route or Site-To-Site VPN).

Conditional Forwardes

Let’s try the DNS resolution from my domain controller:

DNS resolution from my domain controller

As you can see, the name is well resolved. From this point, my On-Premises VMs are able to resolve name located in private DNS zone. Now we have to configure DNS Private Resolver to allow services in Azure to resolve On-Premises name.

DNS Private Resolver configuration: Outbound requests

To allow services located in Azure to resolve On-Premises name we have to create an Outbound endpoint and then associate a ruleset to it. A ruleset is basically a conditional forwarding rule.

DNS Private Resolver configuration: Outbound requests

If I open my ruleset called OnPrem you can see that I forward request from the domain SeromIT.local to a DNS server that has the IP 10.10.100.8.

OnPrem. Rules

In Virtual Network Links, I also add each virtual network that requires to resolve On-Premises name.

Virtual Network Links

In the DNS servers configuration of the above virtual network, you have to configure this setting to Default (Azure-Provided).

DNS servers configuration

After this configuration, I connected to a VM located in Azure.

After this configuration, I connected to a VM located in Azure

Found Romain’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!