Skydive Consulting

Introduction

Continuing our previous blog post on good cyber-security practices for Azure cloud platforms, we will now dive into the topic of Private DNS zones which enhances security and manageability. 

10 minutes read – Not needed if you are an experienced platform engineer working with Azure :0)

In the last blog post we briefly ran through the use of private endpoints and private link services in Azure and listed some of the security pitfalls that may be encountered while provisioning Platform as a Service (PaaS) in Azure. The proficient reader, of course, noted that while Azure PaaS services may be exposed through a publicly available endpoint, traffic going from one Azure tenant to another is very unlikely to actually pass through the public internet. 

Azure, of course, has its own backbone network that transports data between its own data centers. However, by adding private endpoint into our cloud infrastructure we create an additional layer of network isolation, encryption and optimized network paths according to Azure’s documentation.  

While adding private endpoints gives the associated resource a private IP address in the VNET where it is allocated, there still are no domain names associated with the resource. This clearly makes it harder for applications that need to access the resource to accurately hit the right endpoint as endpoints may change due to life cycle management or being used in different environments.  

To address this issue, Azure created Private hosted DNS zones, coupling private IP addresses and naming records. This is essentially a phone book for private IP addresses. Thus, when the IP address of e.g. an endpoint change, there is no change required for the client to contact if properly configured. Furthermore, secure data transfer via HTTPs inside Azure relies on certificate information, based on the domain names of the resources.  

Let us start by deploying a standard Storage Account and inspect its different endpoints in the Azure portal: 

As can be seen different endpoints exist for different sub services within the Storage Account. Let us focus on the Blob service and try to resolve its IP address from a personal computer outside of our Azure private network: 

So, the endpoint resolves to a data center within Azure IP ranges as can be verified lookup on the current Azure documentation. 

Fortunately, we do not (in this case) intend to share our blob data over the public internet, so accessing through the public IP will not work, as we have disabled access from the public internet in our firewall config for the Storage Account. 

Instead, we will configure a private endpoint inside our VNET which allows us to get an internal IP address for our Blob container: 

Making a new dig on the endpoint gives the following results: 

• What we see is that skydivednsstorageacc.blob.core.windows.net. is a CNAME (Canonical Name) record pointing to skydivednsstorageacc.privatelink.blob.core.windows.net. 
• skydivednsstorageacc.privatelink.blob.core.windows.net is also a CNAME pointing to blob.db4prdstr13a.store.core.windows.net. 
• blob.db4prdstr13a.store.core.windows.net. is an A record pointing to the IP address 20.60.205.164. 

So, after adding a private endpoint inside out VNET, from the outside the lookup although going through a couple of CNAME records still resolves to the public IP address, which is the desired result. 

Now, let us try to make a lookup from a VNET inside our Azure Tenant. We will create the following hub and spoke like scenario: 

The DNS configuration of the VNETs is configured to use the Azure provided public DNS servers in this case. 

Signing into the VM and doing the lookup from there gives almost the same result as before: 

So, we do not get the private IP address of the private endpoint that we want to securely communicate with the Storage Account over the VNET peering. To the rescue comes Azure Private DNS zones, which will allow us to create an A record in the private DNS zone as follows: 

Doing the lookups again from either the public internet, on premises or any of the VNETs still does not make any difference, we still get the public IP address of the storage account. We need to associate the Private DNS zone with the VNETs for DNS lookups to get the private IP address: 

Doing the lookup from VM1: 

The answer section is now boiled down to a CNAME record which points to the Private DNS zone which we have just created, hence the lookup is being directed to that particular DNS zone for resolution and we get the correct private IP address that allows the VM1 to connect to the Storage Account via the VNET peerings as intended. 

Resolving from the public internet using public resolvers as shown earlier obviously did not change as the DNS we created is entirely private to our setup. 

Private DNS zone values

Besides the blob zone that we utilized in the example above, private DNS zones exists for a long range of Azure services, ensuring that the segregation between public and private DNS resolution can be achieved. See the full list here: Documentation. 

Auto registering VMs

In some cases, it might be beneficial to auto register VMs within a private DNS zone.  This option can be enabled through the setting on the virtual network links connecting the VNET and the private DNS zone. More information here, Auto registration feature in Azure private DNS zones. 

Multiple Private Endpoints

Private endpoints as pointed out in this blog post and the previous one, may be created in the same VNET as the resource we want to connect to. However, we may choose to add private endpoints to multiple VNETs. Furthermore, this is possible across tenants enabling data providers to share data securely for client in their own tenant. This is obviously a great feature for easy, secure, and thus private sharing of data.  

Resolution from on premises

Some enterprises still rely on data centers and data sources managed on-premises. Accessing the data through a site-to-site/point-to-site VPN or ExpressRoute connection also needs to handle DNS resolution working seamlessly both ways. We will explore patterns for hybrid DNS resolutions in future posts.

Conclusion

Configuring private endpoint and private DNS zones as described in these articles are fundamental features in order to keep any Azure platform secure, private and manageable. Getting different DNS results from different resolution points can cause confusion or appear “magical” at times, but as we seen in the above example, it makes perfect sense to segregrate public and private traffic. We will continue these blog post with more technical insights.