In today’s fast-paced digital landscape, secure and reliable network infrastructure is paramount. Azure, Microsoft’s cloud computing platform, offers a powerful solution for achieving this goal through its Site-to-Site VPN, Point-to-Site VPN, and ExpressRoute private connections.
In this comprehensive guide, we delve into how to query and resolve private DNS zones over Azure Point-to-Site VPN and Azure DNS Private Resolver without the need to use a VM-based DNS conditional forwarder.
Table of Contents
Introduction
As an increasing number of services transition to a cloud-native approach, organizations are progressively moving away from relying on DNS servers. This trend mirrors the emergence of new “greenfield” organizations that embrace full cloud-native solutions and opt not to utilize traditional domain controllers. Moreover, there is a growing inclination among organizations to avoid the provisioning of server-based DNS services.
In the past, when utilizing an Azure Point-to-Site VPN, Site-to-Site VPN, or ExpressRoute connections, it was necessary to configure a DNS conditional forwarder to resolve private DNS names within the Azure environment. This approach entailed additional infrastructure, increased maintenance efforts, and a higher likelihood of encountering DNS-related issues, as the saying goes, “It’s always DNS!”.
In today’s landscape, where many individuals work remotely and may require access to Azure-hosted resources, the question arises: How can DNS resolution be effectively managed across a Point-to-Site VPN connection to resolve Private Endpoint services like Azure storage accounts, Azure SQL databases, etc?
// A private endpoint is a network interface that uses a private IP address from your virtual network. See the list of all Azure services that support a private endpoint and the Azure Private Endpoint DNS configuration.
Well, we have Azure DNS Private Resolver service to the rescue. Microsoft announced Azure DNS Private Resolver’s general availability way back in October 2022. By using this service, you will be able to resolve DNS names hosted in Azure DNS private zones from on-premises networks, as well as DNS queries originating from Azure virtual networks that can be forwarded to a specified destination server to resolve them.
Related: Learn how to Design and Implement Microsoft Azure Networking Solutions.
Private DNS Resolver Architecture
Azure DNS Private Resolver enables you to query Azure DNS private zones from your on-premises environment and vice versa, without deploying VM-based DNS servers in Azure. It’s fully managed by Microsoft and built with high availability, and zone redundancy.
The good news is, that you don’t need to change any DNS client settings on your virtual machines to use the Azure DNS Private Resolver. This also benefits Private Endpoint resources, so you can access them from on-premises without pointing to the DNS forwarders.
As mentioned earlier, before the availability of Azure DNS Private Resolver, there was a need to deploy a DNS forwarder virtual machine (VM) to enable on-premises servers to handle requests directed to the Azure private DNS service. The diagram below provides a visual representation of the specific steps involved in this complex name resolution process.
So, we have a conditional forwarder on the on-premises DNS server that forwards requests to an Azure IaaS DNS forwarder VM, and a private DNS zone is linked to a virtual network. Thus, requests to the Azure service then resolve to the appropriate private IP address.
The diagram below illustrates the architecture of DNS Private Resolver integration in the Hub VNet. First, you need to have Azure ExpressRoute or Site-to-Site VPN between on-premises networks and Azure virtual networks, and the spoke virtual network, is also peered to the Hub VNet. As a side note, the Azure landing zone design pattern recommends using a hub-spoke network topology with a centralized Azure DNS Private Resolver architecture deployed in the hub network.
The Private DNS zone records will be resolved via the Inbound Endpoint. The Inbound Endpoint requires a dedicated subnet in your Azure virtual network. It will use an IP address from this subnet to communicate to the DNS private resolver. Then the DNS private resolver, will go and resolve against Azure Private DNS. You can also resolve on-premises resources and domains from Azure, via Outbound Endpoint with conditional rule.
Let’s take a closer look at the Azure DNS Private Resolver architecture.
In the diagram below, we have an on-premises data center that is connected to Azure via ExpressRoute and/or a Site-to-Site Azure VPN Gateway connection. Remote and external clients are connected through a Point-to-Site (P2S) VPN tunnel. Network components include two local DNS servers. One uses the IP address 192.168.0.1 and the other uses 192.168.0.2. Both servers work as resolvers or forwarders for all computers inside the on-premises network.
A network administrator creates all local DNS and Azure endpoints on the local servers. Conditional forwarders are configured on these servers for the Azure Blob Storage and Azure API Management services. Those forwarders forward requests to the DNS Private Resolver Inbound connection (more on this in the next section). The Inbound endpoint uses the IP address 10.0.0.8 and is hosted within the hub virtual network.
Azure DNS Private Resolver relies on Inbound and Outbound Endpoints, and Conditional Rulesets, to resolve DNS queries, and to forward DNS requests to destination IP addresses.
For our use case with Azure Point-to-Site (P2S) VPN, we will focus on the Inbound functionality of Azure DNS Private Resolver only.
Related: How to use Azure VPN Gateway to Route Traffic Between Spoke Networks.
Prerequisites
To follow this article, you need to have the following:
1) Azure subscription – If you don’t have an Azure subscription, you can create a free one here.
2) One or more virtual networks deployed with their appropriate IP subnets. Please check the following quickstart guide to create a virtual network.
- You need one subnet dedicated to Azure DNS Private Resolver to resolve DNS queries. The subnet must be a minimum of /28 address space or a maximum of /24 address space.
- You need one subnet dedicated to the VPN gateway. It’s best to specify /27 or larger (/26,/25, etc.).
- You need one subnet dedicated to your workloads and to be used by the private endpoint.
3) Azure VPN Gateway deployed in the virtual network. There is nothing special to set on the Azure VPN gateway besides its provisioned and configured correctly. Please check the following guide to create a VPN gateway for your Hub VNet.
4) Functioning Azure point-to-site environment. Follow the instructions to create a point-to-site VPN and configure a point-to-site VPN gateway. It’s strongly recommended to use Microsoft Entra ID authentication with Point-to-Site VPN connections. See how to configure Microsoft Entra ID (formerly Azure AD) authentication for the VPN gateway.
5) You need a private endpoint (i.e. Storage Account, App Service, or SQL Database) linked to the virtual network. In this example, we have a Private Endpoint enabled for our storage account for the blob sub-resource (IP 10.9.2.5). The same will apply to files, tables, queues, etc. By default, when you create a Private Endpoint, the Private DNS Zone integration is enabled, so you don’t need to create a Private DNS Zone manually.
6) Deploying and configuring Azure DNS Private Resolver (more on this in the next section). Check the Azure DNS Private Resolver pricing page.
Assuming you have all the prerequisites in place, and the Virtual Network is linked to your Virtual Network gateway as part of the “Point-to-Site VPN” setup, take the following steps.
Deploy Azure DNS Private Resolver
Open the Azure portal and search for the DNS Private Resolvers in the search bar.
1) Click Create DNS private resolver.
2) Select your desired Subscription and Resource Group. (We recommend placing the DNS Private Resolver in the same resource group as your Virtual Network and Virtual Network Gateway, for this example, we are placing the DNS Private Resolver centrally in the hub virtual network).
3) Give the instance name and select your region. Please note that the DNS private resolver and virtual network must exist in the same location, so the region you select will affect the available virtual networks that you can use. Select your desired Virtual Network and click Next: Inbound Endpoints >.
4) Next is to add our Inbound Endpoint and create the Private DNS Resolver Subnet. On the Inbound Endpoints page, click “+ Add an endpoint“.
5) Enter your desired Endpoint name. If you have already created a subnet for DNS Private Resolver, select it here, otherwise, click “Create New“.
6) Enter your subnet name and subnet address range, then click “Create” and click “Save“. Remember the subnet must be a minimum of /28 address space or a maximum of /24 address space.
7) We will skip the Outbound Endpoints configuration in this scenario because we only need to resolve Azure services (Private Endpoints) over Azure Point-to-Site VPN.
8) Last, select “Review + Create” and then click “Create“.
The deployment of Azure DNS Private Resolver will take a few minutes to complete.
Modify Point-to-Site VPN DNS
In the next step, we need to update and modify our Point-to-Site VPN client DNS configuration file, so external clients can resolve and look for private endpoint services.
Now that the DNS Private Resolver has been deployed with an Inbound Endpoint, allowing the lookup of private endpoints, we need to add the private IP address of the DNS Private Resolver to our Point-to-Site VPN configuration. To do so, take the following steps:
1) First, we need to get the newly created private IP address of the DNS Private Resolver “Inbound Endpoint“.
2) Navigate to the DNS Private Resolver in the Azure Portal.
3) Open your DNS Private Resolver service and under Settings select Inbound Endpoints. Take note of the private IP address of the Inbound Endpoint. In this example, it’s 10.9.5.4.
4) Now that you get the Private Inbound IP address, we need to add/modify the DNS Server Entry into our Azure VPN configuration file, so that our DNS queries will respond with a private endpoint; you will need to modify the “azurevpnconfig.xml” file and reimport it to the Azure VPN Client.
5) Next, download the VPN client .zip file from the Azure Virtual Network Gateway page and then extract it.
6) Browse to the unzipped “AzureVPN” folder, then right-click “azurevpnconfig.xml” and edit it in Visual Studio Code or with any of your favorite editors. Then under the <clientconfig>, <dnsservers> tags, delete the <DnsServerEntry> and </DnsServerEntry> tags first, and then modify (add the IP listed between <dnsserver> and </dnsserver> tags with the IP of your Inbound endpoint copied earlier). In this example, we have more than one <dnsserver> entry, we need to update both.
7) Once you saved your configuration changes, you can then import the XML configuration file into the Azure VPN Client. This step must always be done after making any changes to the VPN configuration.
As you can see in the figure below, our Azure VPN client is connected to my customized configuration profile. Note the VPN DNS Server IP address(es) is set to the Inbound endpoint of our Azure DNS Private Resolver.
Please note that if you set the tunnel type to OpenVPN with Microsoft Entra ID (formerly Azure AD), then the client utilizes DNS Name Resolution Policy Table (NRPT) entries, which means DNS servers will not be listed under the output ipconfig /all on the client machine. To confirm your DNS settings are set correctly on the client, run the Get-DnsClientNrptPolicy in PowerShell.
Get-DnsClientNrptPolicy | FT NameServers -AutoSize
Test Private Endpoint over Point-to-Site VPN
In the last step, we need to verify that we can resolve and reach the resource behind a private endpoint by running Test-NetConnection PowerShell or the Ping command. In this example, we have a blob storage account. As shown in the figure below, we should get the private IP address (10.9.2.5) of that resource back and should be able to connect to that resource privately.
Please note that any new private endpoints that you create and link to the same Virtual Network, will be accessible instantly without any additional changes on the Azure VPN client side.
As mentioned earlier, if you have a Hub and Spoke network topology, then you can place the DNS Private Resolver centrally in the Hub virtual network, and then use the DNS forwarding ruleset to link to other peered (Spoke virtual networks). See how to use DNS Forwarding Ruleset with Virtual Network Links (Virtual network links for DNS forwarding rulesets enable resources in other VNets to use forwarding rules when resolving DNS names).
IMPORTANT: If you are already using custom-based DNS servers on your Hub virtual network, then you must update and use the Default (Azure-provided) DNS servers as shown in the figure below. The key to realize here is that an Azure P2S client will get assigned a DNS server whatever the VNet containing the VPN gateway has configured as a custom DNS server, even if you have customized the “azurevpnconfig.xml” file as described above, the VPN client will still get the custom DNS server as well.
If you still have custom-based DNS servers set on your Hub virtual network, then you must ensure that your custom VM-based DNS server has a conditional DNS forwarder configured to forward queries to (Azure wire server virtual IP 168.63.129.16). Why do you want to do that? This could be a temporary phase (in a coexistence scenario) until you decommission your custom VM-based DNS solution. Otherwise, a Point-to-Site (P2S) VPN with Azure DNS Private Resolver (Inbound Endpoint) can’t resolve records in the Private DNS Zone.
In summary, for Point-to-Site (P2S) VPNs you want to have the Hub VNet using an IP address as a DNS server, either a DNS proxy such as Azure Firewall, the DNS Private Resolver’s inbound endpoint IP address, or the default (Azure-provided) DNS.
There you have it. Happy DNS Private Resolving with Azure Point-to-Site VPN!
Wrapping Up
In this comprehensive guide, we have explored the powerful capabilities of Azure Point-to-Site VPN and Azure DNS Private Resolver. Implementing these services effectively can bolster your network security, enable remote access to Azure resources, and achieve seamless DNS resolution within your virtual network.
Azure DNS private resolver bridges on-premises DNS namespaces with private DNS zones hosted on Azure DNS without the burden of deploying VM-based custom DNS servers. You can resolve DNS queries from on-premises networks and do conditional forwarding to on-premises DNS zones.
The only factor that you want to look at is the cost of the Azure DNS Private Resolver. At the time of this writing, the Azure DNS Private Resolver for 1 X Inbound endpoints costs around CHF 159/month in Swiss Franc. The cost is the same for the 1 X Outbound endpoints as well. So if you use both endpoints, you end up paying around CHF 318/month.
This would be considerably more expensive than a lower-end VM deployed in Azure and acting as a DNS server or DNS forwarder. The choice is yours if you would prefer to stay using IaaS services or move to a PaaS alternative solution.
If you want to learn more, check out my recently published video course on Designing and Implementing Microsoft Azure Networking Solutions.
__
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.
-Charbel Nemnom-
