Azure DNS Private Resolver
It’s always DNS! I’m sure you’ve heard this phrase before. DNS is 1 of the most underrated services on the internet, but probably also 1 the most important. Especially in hybrid environments with Private DNS in Azure and multiple on-premise domains, there is a good chance that DNS does not work as intended.
DNS, the “phone book” of the internet, is something everyone uses, even without realizing it. There are public DNS records, which can be used by anyone. Private DNS records that are only used within an organization on-premise or within the Azure tenant. In addition, you also see hybrid DNS where you use private DNS records in Azure for e.g. Private Endpoints and often also have a DNS running on-premise within the organization.
The problem with this is that these 2 Private DNS systems can’t talk to each other by default. Now there are several options to solve this. One of the new and preferred methods within Azure is currently the Azure Private DNS Resolver. The big advantage of this is that it is a PaaS service, so you don’t have to manage the underlying infrastructure yourself and possibly update or scale it up. When setting up the DNS Private Resolver, there are several options you can do, depending on your ultimate goal.
- Purely as an internal DNS resolver- This mode is actually redundant because you can use the standard Azure DNS servers for this. It can also be used by the on-premise DNS servers to query private DNS records in Azure
- As a Hybrid DNS Private resolver which also forwards requests to the on-premise DNS servers. - Once you choose the mode, you can forward the Private DNS resolver requests for records from the on-premise DNS resolver.
This second one in particular is very powerful. You can use it to control within the DNS resolver where certain requests should be handled. For example, if you have a split DNS, where you use the same domain name internally and externally but for different purposes. So you could forward requests for the specific domain name from the Azure DNS Resolver to the on-premise DNS resolver, which in turn forwards records that may be in the external domain to it.
To set up the Azure DNS resolver, you need to take into account that depending on the chosen mode, you will need 1 or 2 subnets which can be assigned to the inbound endpoint for the DNS server or the outbound endpoint.
The inbound endpoint is, as the name suggests, the subnet on which the requests come in. From this sequence, the first address will be used to send the answers. That address actually runs on a load balancer which then forwards the request to an available instance of the DNS Resolver. This way, you technically only have to allow 1 address in your firewall. For example, if an Azure Firewall is also used, you can have it forward all traffic to the Azure DNS resolver as a DNS proxy. This applies to traffic within Azure, but also from on-premise. This way, only your Azure firewall address needs to be known, and you also have the freedom to change the proxy address in Azure Firewall.
It works a little differently for the outgoing endpoint, where the traffic can come from multiple instances. For outgoing traffic, the entire subnet on the firewall will always have to be allowed. On the outgoing endpoint, you then specify exactly for which entry a request should be forwarded to which DNS server. So, for example, you can have all requests to your internal domains forwarded to your on-premise DNS servers. But you could also say that you always want a specific record to be resolved by a specific remote server.
Of course, it is important to note that TCP/UDP port 53 is allowed from the outgoing endpoint to the on-premise or remote server, and also that on-premise DNS allows traffic from the outgoing endpoint subnet.
So if you have a hybrid DNS solution and can’t say goodbye to your local DNS yet, Azure DNS Private Resolver is certainly a good solution for a scalable and easily maintainable solution that allows you to have the Private DNS records and your own on-premise records easily resolved by the same end-point.