Eduard Keilholz

Hi, my name is Eduard Keilholz. I'm a Microsoft developer working at 4DotNet in The Netherlands. I like to speak at conferences about all and nothing, mostly Azure (or other cloud) related topics.
LinkedIn | Twitter | Mastodon | Bsky


I received the Microsoft MVP Award for Azure

Eduard Keilholz
HexMaster's Blog
Some thoughts about software development, cloud, azure, ASP.NET Core and maybe a little bit more...

Azure DNS Private Resolver

Have you ever created a network in Azure? Have you ever gone so far that you need to connect to your resources from your on-premises network? You have probably created a VPN connection (for example using a Point-to-Site connection) to your VNet and ran into some trouble because you are not able to resolve the hostnames of resources in your network.

To overcome this problem, you have to create your own DNS that resolves name hostnames in your VNet, or else forward the DNS request to Azure’s default DNS. And now you have yet another VM and service (the VM for the DNS, and the DNS Service itself) to maintain. Luckily, there is a new service called the Azure DNS Private Resolver.

What is the Azure DNS Private Resolver

Well, in fact, this private resolver does exactly what’s described above. It tries to resolve hostnames in networks it is attached to, and forwards the DNS request to a different DNS Service when it could not resolve the hostname. You create inbound endpoints as properties of your DNS resolver. These inbound endpoints are deployed in a subnet of your VNet and act as ‘tentacles’ of the DNS Private Resolver to reach into your network.

Let’s assume you have already deployed a VNet in Azure, and this VNet contains a subnet dedicated to the inbound endpoint:

resource VNet 'Microsoft.Network/virtualNetworks@2021-05-01' existing = {
  name: vnetName
  scope: resourceGroup(vnetResourceGroup)
  resource inboundEndpointSubnet 'subnets' existing = {
    name: subnetName
  }
}

An inbound endpoint must be assigned to a subnet that is reserved specifically for that inbound endpoint. No other resource can exist in the same subnet with the inbound endpoint.

Now let’s create the DNS Private resolver:

resource dnsResolver 'Microsoft.Network/dnsResolvers@2022-07-01' = {
  name: 'my-dns-private-resolver'
  location: location
  properties: {
    virtualNetwork: {
      id: VNet.id
    }
  }
}

Once the resolver is in place, you can now go ahead and deploy the inbound endpoint:

resource dnsResolverInbound 'Microsoft.Network/dnsResolvers/inboundEndpoints@2022-07-01' = {
  name: 'my-dns-private-resolver-inb001'
  location: location
  parent: dnsResolver
  properties: {
    ipConfigurations: [
      {
        subnet: {
          id: VNet::inboundEndpointSubnet.id
        }
        privateIpAllocationMethod: 'Dynamic'
      }
    ]
  }
}

That’s all there is to it. The inbound endpoint can now resolve names in your VNet. The inbound endpoint will be assigned an IP Address. If you configure your VNet to use that IP address as DNS Server and then create the Point-to-Site connection using an Azure Virtual Network Gateway, you will see that the clients are configured to also use the same IP Address as a DNS Server. This makes that you can now resolve resources to internal network IP Addresses through your VPN connection.