Azure Private DNS on–premises



Our typ­ical cus­tom­ers at synvert are high-growth scale-ups to large enter­prises and cor­por­ate com­pan­ies. We help them increase their team per­form­ance and sup­port cloud strategy and imple­ment­a­tion.  As part of our quest, we com­monly work with hybrid cloud setups where on-premises need to co-exist and inter­act with pub­lic cloud pro­viders. In this art­icle, we’ll walk you through one com­mon use case with Azure Private DNS. 

Using Azure Private DNS to give access to private resources

Azure Private DNS is a ser­vice that gives you an easy and secure solu­tion to register your private DNS records for all your infra­struc­ture ele­ments inside Azure. But how does Azure Private DNS work? First, you need to cre­ate your private DNS zone and link it within a Vir­tual Net­work. The private DNS zone is a resource where you will place the records and link to a Vir­tual Network.

You can find all the inform­a­tion about the bene­fits, cap­ab­il­it­ies, prices, and so on here, on the Azure Doc­u­ment­a­tion web page.

But what to do if giv­ing domain res­ol­u­tion only for your cloud ser­vices is not enough? Most of the time, not all your net­work com­pon­ents, like serv­ers or employ­ees’ com­puters are on the cloud net­work scope, being on-premise or at your employee’s home. So what to do if these ele­ments need access to those DNS records as well?

Internal Tools DNS Flow Request vs External Tools DNS Flow Request 
Fig­ure 1: Internal Tools DNS Flow Request vs External Tools DNS Flow Request — schema based on https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns#on-premises-workloads-using-a-dns-forwarder 

1. Let’s set up a VPN

To give make those resources access­ible to your Azure Private DNS solu­tion, we need to ensure that they have access to the Azure net­work some­how. To do that, let’s start to set up a VPN solu­tion, using a vir­tual machine with a Unix-based oper­at­ing sys­tem installed. To eas­ily install an Open­VPN Server, we sug­gest angristan Open­VPN installer that you can find here and counts with more than 6.9k stars.

2. Con­fig­ure your VPN

Now that we have a work­ing VPN solu­tion, there are some con­fig­ur­a­tions that you need to do, to ensure that your cli­ents can use your Azure Private DNS on-premises. These con­fig­ur­a­tions are to:

  • users are using your DNS when they are con­nec­ted to the VPN
  • DNS requests are for­war­ded from your VPN machine to the private DNS

On MacOS and Win­dows cli­ents you only need to add the fol­low­ing line to your VPN server config.

push “dhcp-option DNS <internal-vpn-server-ip>”

On Linux cli­ents, apart from the con­fig­ur­a­tion above, make sure to add the next three lines on the cli­ent VPN file, because resolve.conf will be edited, and a refresh must be done.

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

3. Add a DNS forwarder

With those changes, the first two phases are done, so let’s con­tinue to the next one. As men­tioned on Azure docs, to use this DNS ser­vice on-premises, we have to some­how for­ward our on-premises machine’s DNS requests that are arriv­ing at the VPN server to the Azure Private DNS. To do that, we imple­men­ted a DNS server (bind9) that is work­ing only to cache and for­ward DNS requests.

acl vpn {
	<vpn-network>/24;
};
options {
    directory "/var/cache/bind";
    listen-on port 53 { <vpn-interface-ipv4>; };
    listen-on-v6 { <vpn-interface-ipv6>; };
    forwarders { 168.63.129.16; };
    forward only;
    recursion yes;
    allow-query { vpn; };
    dnssec-enable yes;
    dnssec-validation yes;
    auth-nxdomain no;    # conform to RFC1035
};

As you can see, there are sev­eral con­fig­ur­a­tions that you need to do on the bind9 ser­vice. First, for secur­ity reas­ons, we cre­ated an ACL, called VPN with our VPN net­work to have bet­ter con­trol over who can access the name server. Next, let’s enable bind9 ser­vice only on the VPN inter­face. This way, we imple­men­ted another layer of secur­ity, because port 53 will be listen­ing only on that inter­face. If you are using IPv6, make sure that you include it too.

As for our for­ward­ers, we set 168.63.129.16, a vir­tual pub­lic IP address that is used to facil­it­ate a com­mu­nic­a­tion chan­nel to Azure plat­form resources. With that for­warder, and with a vir­tual net­work link between our VPN machine vir­tual net­work and our Private DNS Zone (image below), we are ensur­ing that DNS requests are being made to our private DNS too.

Virtual network link between our VPN machine virtual network and our Private DNS Zone
Fig­ure 2: Vir­tual net­work link between our VPN machine vir­tual net­work and our Private DNS Zone

Last but not least, let’s use our ACL cre­ated pre­vi­ously, on the allow-query sec­tion to ensure that only requests from our VPN net­work are accepted.

And it’s done, now you are able to resolve your private domains on-prem!