Hello Folks,
I’m not sure when this became a series, but it’s looking like it’s going to be ongoing. I’m hoping it can give the community a sense of how you can slowly adopt cloud services to enhance your on-prem environment.
It started a few weeks ago with the post on how I needed to replace the edge device on my home network. Then I followed up with how I now can use the site-to-site VPN I set up to access (RDP & SSH) all the servers in my environment using the Bastion host on Azure.
But now I’m at a point where I’ve got demo servers and services on both sides of the VPN. Name resolution is fast becoming an issue. How do I set up a DNS structure to efficiently resolve server IP addresses from an on-premises environment and vice versa without deploying VM-based DNS servers.
There is nothing wrong with VM-based DNS servers. I’ve done it in the past and I know a lot of people are doing it today. Mostly because there was no alternative solution. That’s when I noticed Azure Private Resolver. It’s a preview service that in conjunction with Azure Private Zones allows you to do just that. Setup an end-to-end name resolution structure without the headaches of managing/patching/protecting another VM and all while providing the following benefits.
- Fully managed: Built-in high availability, zone redundancy. No need to deploy multiple VMs in order to address the single point of failure when running a single VM.
- Cost reduction: Reduce operating costs and run at a fraction of the price of traditional VM solutions. Both in service costs (the cost of the VM Itself) and the operational costs of managing yet another VM (or more) just to do DNS.
- Private access to your Private DNS Zones: Conditionally forward to and from on-premises.
- Scalability: High performance per endpoint.
- DevOps Friendly: Build your pipelines with Terraform, ARM, or Bicep.
An Azure DNS Private Resolver has one, or more inbound endpoints established that are used as the destination for DNS queries. The resolver's outbound endpoint processes the DNS queries based on a DNS forwarding ruleset that you configure. DNS queries that are initiated in networks linked to a ruleset can be sent to other DNS servers.
Here is how I implemented that in my environment.
Current DNS structure On-Prem.
I’m currently using an AD Integrated zone DNS running on a Windows Server 2022 DC. My local zone is corp.azrtestbench.com (I used corp because I set this up late one night last week and my brain was out of original ideas.)
In my Hub resource group – and if you’re asking, Yes. I have a hub and spoke architecture for my demo subscription. There is a great write-up on Hub-spoke network topology in Azure here https://aka.ms/blog/HubandSpoke that details a hub-spoke topology in Azure. The hub virtual network acts as a central point of connectivity to many spoke virtual networks by using virtual network gateways or virtual network peering. The hub can also be used as the connectivity point to your on-premises networks using point-to-site, site-to-site VPNs, and/or ExpressRoute.
The spoke virtual networks peer with the hub and can be used to isolate workloads. Thus allowing me to be able to spin up a demo in its own resource group and VNet and trash it when I’m done with it without having to constantly rebuild my access, name resolution, and automation tasks.
Diagram of my DNS architecture with both On-Prem and in the cloud environments
Azure Private DNS Zone
To set up the name resolution I started with an Azure Private Zone. As mentioned in the documentation, an Azure Private DNS gives you a reliable, secure name resolution service in a VNet without the need to add a custom DNS solution. You can even use your own custom domain name. I did…
- On-Premises DNS zone = corp.azrtestbench.com
- In Azure DNS Zone = cloud.azrtestbench.com
The records contained in “cloud.azrtestbench.com” are NOT resolvable from the Internet hence the name Azure Private DNS Zone. It only works only from within the VNets that are linked to it.
I linked my private DNS zone to all the VNets in my environment by creating virtual network links and I enabled autoregistration to automatically manage the life cycle of the DNS records for the VMs that I deploy in those VNets.
With this Private Zone, all my VM automatically register their IP when they start.
Azure DNS Private Resolver
Now that I have a private zone setup, I need to set up the service to query Azure DNS private zones from an on-premises environment and vice versa without deploying VM-based DNS servers. The DNS query process when using an Azure DNS Private Resolver is as described below: (List below is a copy/paste from https://aka.ms/blog/HowAzrDNSWorks )
- A client in a virtual network issues a DNS query.
- If the DNS servers for this virtual network are specified as custom, then the query is forwarded to the specified IP addresses.
- If Default (Azure-provided) DNS servers are configured in the virtual network, and there are Private DNS zones linked to the same virtual network, these zones are consulted.
- If the query doesn't match a Private DNS zone linked to the virtual network, then Virtual network links for DNS forwarding rulesets are consulted.
- If no ruleset links are present, then Azure DNS is used to resolve the query.
- If ruleset links are present, the DNS forwarding rules are evaluated.
- If a suffix match is found, the query is forwarded to the specified address.
- If multiple matches are present, the longest suffix is used.
- If no match is found, no DNS forwarding occurs and Azure DNS is used to resolve the query.
Azure DNS Private Resolver architecture from https://aka.ms/blog/AzureDNSPrivateResolver
After deploying the Azure DNS Private Resolver, (find the step-by-step here), I configured the inbound endpoint and the outbound endpoint in 2 pre-configured subnets
Configure a DNS forwarding ruleset
After installing the DNS Forwarding Ruleset,
I’m ready to configure my DNS forwarding rules and Link my VNets to the ruleset.
A DNS forwarding rule includes one or more target DNS servers that will be used for conditional forwarding and is represented by:
- A domain name,
- A target IP address,
- A target Port and Protocol (UDP or TCP).
My first rule will define how my Resolver will forward queries to the Private Zone I created earlier for anything that is in the linked vnets configured in the private zone. Please note that I’m using the IP address of the inbound endpoint as the destination address.
My second rule is for my on-prem environment. Same process here, but I’ve configure this rule to point to my local on-prem DNS server for anything in the “corp.azrtestbench.com” zone.
Finally, I have linked all the VNets I want to cover in my Azure environment.
On-Prem setup
On my Windows Server 2022 configured both as a DC and a DNS server, I’ll configure a conditional Forwarders. That is a DNS feature that allows me to resolve names in a private namespace. When my on-prem DNS server receives a client query request for a host address that is not part of its authoritative namespace, it starts the standard resolution process.
Because I’m setting up a Conditional Forwarder the local DNS server will forward the request to an authoritative DNS for the namespace of the query. In my case, anything for “cloud.azrtestbench.com” will be sent to the Azure Private Resolver inbound endpoint.
Results
I now have a complete end-to-end name resolution system that I don’t have to worry about (No patching, no single point of failure.
From on-prem. The “cloud.azrtestbench.com” zone queries are sent through the conditional forwarder to the inbound endpoint of the Private resolver that returns the right address.
And from a VM in Azure, anything in the “corp.azrtestbench.com” zone through the DNS Ruleset gets sent to the on-prem DNS server.
If you have a hybrid environment…. Check out the links in this article. And please leave feedback in the comments below. It really helps make the product better.
Cheers!
Pierre
Microsoft
