Using custom DNS as Hybrid DNS for Azure and on-premises
- Azure DNS offers both Public DNS and Private DNS services.
- Azure Private DNS zones provide a secure DNS service only for your Azure virtual networks. The records in Azure private DNS zones cannot be resolved via DNS lookups from outside Azure virtual networks.
- To resolve the records of an Azure private DNS zone from your virtual network, you must link the virtual network with the zone. Such a link is called a Virtual Network Link
- Azure's default DNS service for Virtual Networks is provided via 168.63.129.16. All DNS lookups to this IP address must be recursive.
Why Custom DNS?
- If your infrastructure is entirely on Azure, you may use the Azure Private DNS zones as your DNS service for private workloads deployed in your Azure virtual networks and avoid the deployment of any custom DNS solution.
- If your infrastructure is deployed across both on-premises and Azure, then you may leverage your on-premises custom DNS to resolve records for both on-premises private domains and Azure private DNS zones.
UPDATE (17th MAY 2022): Microsoft announced the preview of a new service called Azure DNS Private Resolver which removes the need of the custom DNS solution explained in the remainder of this article. This service is currently in public preview only in certain regions, but once it becomes GA globally, it will help customers eliminate the cost and administration of custom DNS solutions.
Primary use-case for Azure private DNS zone
If you use private endpoints for Azure PaaS services, then your PaaS service private endpoints will use private DNS zones for the DNS A records associated with the private endpoints. For example, if you you deploy an Azure SQL PaaS service with endpoint azsql.database.windows.net and create a private endpoint for this service, Azure will create a DNS A record for azsql.privatelink.database.windows.net (associated with a private IP from the relevant virtual network) in the privatelink.database.windows.net private DNS zone.
Using custom DNS with Azure private DNS zones
Even if you extend your distributed on-premises DNS solution (e.g. AD DNS, EfficientIP, Infoblox, Bluecat, etc.) to Azure by deploying instances within your Azure virtual networks, lookups from your on-premises clients for records in Azure private DNS zones will still be unresolvable as the DNS queries will originate from outside your Azure virtual networks. For such lookups to work, you must do the following:
- Use conditional forwarders on your custom DNS for Azure PaaS public DNS zones (e.g.
database.windows.net) to send traffic to a DNS forwarding instance within your Azure virtual network. Azure creates a CNAME in the public DNS zone (e.g.database.windows.net) that redirects resolution to the private DNS zone (e.g.privatelink.database.windows.net). - Deploy a solution to forward DNS lookups from your custom DNS to Azure's DNS service (168.63.129.16). This solution may be another DNS server (not part of your distributed custom DNS platform), DNS proxy on Azure Firewall or a Custom Firewall NAT policy that forwards traffic destined to a specific IP, to the Azure DNS service (168.63.129.16). If you already have firewalls in Azure, then using NAT policies with the firewall is a good solution. For example, you may choose a specific IP (not attached to anything) in your virtual network (say 10.10.0.100) for the conditional forwarder for database.windows.net on your custom DNS to forward lookups and configure a NAT policy on your firewalls in Azure to send this traffic to Azure's DNS. Of course, the DNS traffic from your conditional forwarder must pass through the firewall to reach 10.10.0.100 for this to work.
Putting all the above together, the image below depicts how 2 on-premises custom DNS solutions (1 PROD and 1 DEV) may be used along with 2 Azure tenants (1 PROD and 1 DEV) with Azure Private DNS zones in the PROD Azure tenant. With this deployment, both Azure and on-premises workloads can resolve records in both Azure and on-premises private DNS zones, thereby facilitating communication between workloads on Azure and on-premises and providing a seamless DNS service.