DNS is an “old” topic in many ways, but it stands always pertinent for simple and complex hybrid, interconnected infrastructure, where seamless communication between a disparate and diverse range of objects poses the requirement of name resolution amongst them.
Azure networking is considered nowadays one of the many moving pieces within a larger context of networking components and with it, the need for bidirectional name resolution.
The common solution to such a requirement was usually to:
- Provide a generic conditional forwarder that points to 168.63.129.16 i.e., to the recursive resolvers in Azure.
- Create separate DNS Zones for Azure resources and utilize your own DNS Servers using VM’s on Azure.
- Combination of the above, with the addition of DNS Zones on Azure.
None of the above options are exhaustive but notably, any combination of the above poses its issues and problems that are outside the scope of this article.
Azure Private DNS Resolver
It comes in the Azure portion of the equation and its job is to make our life easier when it comes to the following distinct needs:
- DNS Resolution of any Azure-based resource from external sources.
- DNS Resolution of external sources from Azure-based resources.
The diagram below demonstrates such a scenario:
The diagram above shows an example of a Hybrid setup that is interconnected using an Azure Site-To-Site or ExpressRoute connection to an on-site network that in this example and for simplicity reasons is divided into two VLANs:
- The on-premises end-user VLAN.
- The on-premises DNS Server environment. (IP’s: 10.10.0.10 & 10.10.0.11)
- The on-premises database environment (DB01 and DB02)
The Azure network and corresponding resource connectivity is composed by using the so-called “Hub and Spoke” network methodology where we essentially have three networks:
- The Hub network contains all of our core networking components.
- VNET -A hosting two VM-based servers on Subnet 01
- VNET -B hosting an Application Service with VNET Integration enabled and an Azure PostGre SQL Server azdb01.database.windows.net, both PaaS-based instances connected using Azure private endpoint.
But let’s zoom in a little closer to our Azure hub network segment:
We see a bunch of items here alongside certain flows, but in sum, this is what we have:
- The inbound endpoint, an IP hosted on a subnet in the hub VNET that receives requests for name resolution from on-premises resources – via an on-premises DNS conditional forwarder for the suffix(es) we are interested in and then asks the Private DNS Zone for the answer to the question.
- An outbound endpoint, an IP address range on a subnet in the hub VNET that sends requests to the on-premises DNS Servers based on a forwarding ruleset for suffixes COTTONSOCK.COM that need to be answered by IPs: 10.10.0.10 and 10.10.0.11 as shown in the image below:
So, let’s take the following cases as an example of a flow based on the diagram shown earlier:
Case target 01: Application Service in VNET B needs to connect and access DB01 on premises so it creates a connection string toward: db01.int.cottonsock.com.
The flow (simplified) is as follows:
- App service which is VNET-integrated on subnet 03 asks for the IP of db01.int.cottonsock.com.
- It uses the Azure DNS Service and uses all public and private DNS information at its disposal and does not find an answer.
- The main hub VNET forwarding ruleset that occupies the outbound endpoint address range is queried, the ruleset is linked to subnet 03 on VNET B.
- The name matches the suffix *.int.cottonsock.com and as such it forwards the question to one of the DNS Servers: 10.10.0.10 & 10.10.0.11
- The DNS Server returns the answer to db01.int.cottonsock.com being: 10.10.4.12
Case target 02: End-users residing at the on-premises network need to access the PostGre SQL database on VNET B on subnet 02.
The flow (simplified) is as follows:
- End-user queries on-premises DNS Server for the address of azdb01.database.windows.net
- On-premises DNS Server forwards queries for prefix *.database.windows.net to Azure Private DNS inbound endpoint: 172.30.2.100
- Private DNS Resolver queries Private DNS Zone repository database.windows.net which has a network link to VNET B subnet B,
- Private DNS Zone returns the private endpoint address IP of the PostGre SQL database.
Conclusion
So that’s it! I sure hope that you have been provided with a better insight into the primary Azure Private DNS Resolver mechanics and allowed to maybe try it out in your environment.
As always you can use Microsoft’s documentation on the topic which covers much more details and special scenarios such as rule precedence, avoidance of end DNS loops, and others here.
Also, don’t hesitate to contact us if you want to clarify about this or any other Azure-related topic.
