10/12/22 Update – Private Resolver is now Generally Available!
Hello again!
Today I’m going to cover the new Azure DNS Private Resolver feature that recently went into public preview. I’ve written extensively about Azure DNS in the past and I recommend reading through that series if you’re new to the platform. It has grown to be significantly important in Azure architectures due to its role in name resolution for Private Endpoints. A common pain point for customers using Private Endpoints from on-premises is the requirement to have a VM in Azure capable of acting as a DNS proxy. This is explained in detail in this post. The Azure DNS Private Resolver seeks to ease that pain by providing a managed DNS solution capable of acting as a DNS proxy and conditional forwarder facilitating hybrid DNS resolution (for those of you coming from AWS, this is Azure’s Route 53 Resolver). Alexis Plantin beat me to the punch and put together a great write-up on the basics of the feature so my focus instead be on some additional scenarios and a pattern that I tested and validated.
I’m a big fan of keeping infrastructure services such as DNS centralized and under the management of central IT. This is one reason I’m partial to a landing zone with a dedicated shared services virtual network attached to the transit virtual network as illustrated in the image below. In this shared services virtual network you put your DNS, patching/update infrastructure, and potentially identity services such as Windows Active Directory. The virtual network and its resources can then be dropped into a dedicated subscription and locked down to central IT. Additionally, as an added bonus, keeping the transit virtual network dedicated to firewalls and virtual network gateways makes the eventual migration to Azure Virtual WAN that must easier.
The design I had in mind would place the Private Resolver in the shared services virtual network and would funnel all traffic to and from the resolver and on-premises or another spoke through the firewall in the transit virtual network. This way I could control the conversation, inspect the traffic if needed, and centrally log it. The lab environment I built to test the design is pictured below.
The first question I had was whether or not the inbound endpoint would obey the user defined routes in the custom route table I associated with the inbound endpoint subnet. To test this theory I made a DNS query from the VM running in spoke 2 to resolve an A record in a Private DNS Zone. This Private DNS Zone was only linked to the virtual network where the Private Resolvers were. If the inbound endpoint wasn’t capable of obeying the custom routes, then the return traffic would be dropped and my query would fail.
Success! The inbound endpoint is returning traffic back through the firewall. Logs on the firewall confirm the traffic flowing through.
Next I wanted to see if traffic from the outbound endpoint would obey the custom routes. To test this, I configured a DNS forwarding rule (conditional forwarding component of the service) to send all DNS queries for jogcloud.com back to the domain controller running in my lab. I then performed a DNS query from the VM running in spoke 2.
Success again as the query was answered! The traffic from the outbound endpoint is seen traversing the firewall on its way to my domain controller on-premises. This confirmed that both the inbound and outbound endpoints obey custom routing making the design I presented above viable.
Beyond the above, I also confirmed the Private Resolver is capable of resolving reverse lookup zones (for PTR records). I was happy to see reverse zones weren’t forgotten.
One noticeable gap today is the Private Resolver does not yet offer DNS query logging. If that is important to you, you may want to retain your existing DNS Proxy. If you happen to be using Azure Firewall, you could make use of the DNS Proxy feature which allows for logging of DNS queries. Azure Firewall could then be configured to use the Private Resolver as its resolver providing that conditional forward capability Azure Firewall’s DNS Proxy feature lacks.
That wraps up this post.
Thanks!
Journey Of The Geek 
But if you already have an azure firewall running with DNS proxy, it can cover you without extra cost/overhead: https://azure.microsoft.com/nb-no/blog/new-enhanced-dns-features-in-azure-firewall-now-generally-available/ – no?
LikeLike
Azure Firewall works if your only requirements are to centralize DNS resolution and to resolve public DNS or Azure Private DNS Zones. It doesn’t support conditional forwarding, so you aren’t able to resolve DNS zones hosted on DNS servers back on-premises (Windows Active Directory-integrated DNS Zones is a common use case). This is a requirement for most enterprises. Today those enterprises BYODNS proxy to address this requirement. The Private Resolver will support conditional forwarding and offer an CSP-managed alternative to BYODNS proxy.
LikeLike
Be careful if you do decide to use the DNS forwarder as the default forwarded in you AD DNS service. I made that mistake. So I set up all on on-premise AD DNS services to forward to the Azure private DNS resolver. I did that because I wanted all on-premise to be able to use the Azure DNS to resolve Azure PAAS service that has been set up with private endpoints and are linked to my Private DNS zones. So all DNS requests that is not my internal domain (including internet domains) hit my on-premise DNS service and then forwarded to the private resolver endpoint IP. Within 2 days, I got a 5k charge on the private DNS resolver inbound endpoint service! I’ve since change the setting to only do conditional forwarding for Azure private dns zones for the Azure PAAS endpoints.
LikeLike
Great feedback! Sometimes going old school can make more sense from a cost perspective!
LikeLike
Pingback: Azure Private Endpoint, Private Link – HAT's Blog
Bit late here but just found this page. I have the same setup, however I can’t get it to work as you have. Outbound I need to link spoke2 vnet with the resolver forwarding ruleset otherwise vm in spoke 2 cannot resolve. In your logs you only show the DNS request from spoke2 outbound subnet to on-prem, there’s no request from vm to outbound, so assume you’ve done the same? I imagine inbound is the same, private DNS zones would need to be linked to private DNS zones – or are you specifying custom DNS servers for your vnet and pointing it at the inbound endpoint?
LikeLike
Hi there!
You do not need to link the Private DNS zone to the spoke. You do need to ensure that you have set the DNS Server settings on the spoke virtual network to the Private Resolver Inbound IP. The Private DNS zones need to be linked to the virtual network that contains the inbound resolver.
LikeLike
Additionally, your rule set needs to also be linked to the virtual network containing the private resolver endpoints.
LikeLike
Right, that makes sense! Think I’m just going to stick with vnet links and using default DNS rather than custom…. your solution is tempting but seeing as you still have to link the vnet to the resolver rule for outbound I may as well just link the private DNS zones too. Means I won’t see the original DNS request from the VM for internal DNS through the Azure firewall, but i’m never going to see it for on-prem requests either (only the request from outbound endpoint to on-prem DNS) so there’s no complete solution anyway.
Appreciate the response, nice article which def helped out so cheers for that!!
LikeLike
It’s been a while since I did this setup, but the rule set should only need to be linked to the VNet containing your resolver. All you should have to do in your spoke is set the VNet dns server settings.
Either solution is valid as long as you have it documented and understand why you made the decisions you did.
Best of luck and thanks for contributing to the conversation!
LikeLike
You are indeed correct! Just tested and works fine, everything through the firewall so there are logs, spoke vnet only needs a peer to hub (no vnet links), def route to fw and custom DNS. It’s a much neater solution, need to confirm there are no reasons we can’t use custom DNS but otherwise will go with it. Thanks again.
LikeLike
Awesome! Great to hear it worked!
LikeLike