Introduction

In this blog post we’ll step through my 7 Step Process to successfully deploy and configure an Azure Private Endpoint. If you want some background of what a Private Endpoint is, and why they are more secure than public endpoints, take a look at this blog post first.

7 Steps to Successfully Deploy an Azure Private Endpoint

My 7 step process involves the following components:

1. Private Endpoint Resource
2. Coupled Azure Resource
3. Target Sub-resource
4. Virtual Network (IP Address)
5. Private DNS Zone Resource
6. A Record
7. Virtual Network Link

It’s worth noting that there are two logical groupings of steps within the 7: steps 1-4 are related, and steps 1-5 are related, so we’ll talk about them as such.

Steps 1 - 4: All about the Private Endpoint

1. Private Endpoint Resource

You may not be aware, but an Azure Private Endpoint is an Azure resource in its own right. If you want a private endpoint for your blob storage account, it’s not a setting you go and set on your storage account. You have to deploy a whole new private endpoint resource.

2. Coupled Azure Resource

Now, although a private endpoint is its own resource, we need to tell that resource which other Azure resource it needs to be coupled with. What is the Azure resource that you want to use your private endpoint for. For example, a specific storage account.

3. Target Sub-resource

Unfortunately, telling your private endpoint resource which coupled Azure resource you want to use it for isn’t enough. Azure resources can have multiple different services, which are all represented by different endpoints. Azure Storage Account is a good example, as it has many services: blob, file, table, queue, dfs, and web. Azure called these “sub-resources”. When deploying your private endpoint resource, you must specify which is your target sub-resource.

4. Virtual Network (IP Address)

We know that at its core, a private endpoint is a private IP address. You must provide the virtual network from which Azure will take an IP address to assign to your private endpoint. When someone says:

"My storage account is inside a vnet"

what they mean is:

"My storage account has a private endpoint associated with it, the IP address of which belongs to my private virtual network"

…but that’s far too many words!

The image below depicts a private endpoint which is being used for the blob sub-resource of a storage account, and is being assigned the IP address 10.0.0.8 from the network 10.0.0.0/26.

Steps 5 - 7: DNS, DNS, DNS!

Step 5: Private DNS Zone

Before we jump straight into Private DNS Zones, we need to first make sure we understand what DNS is.

“The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols.” — Wikipedia

Essentially, it is like a huge phonebook for the internet. It allows us to map between domain name and IP address (and vice versa). If you send a request to a domain name, for example if you type a domain name into your browser, the request is forwarded to a DNS server which will return the associated IP address for that domain.

Public DNS

Let’s step through an example of how public DNS works, and then we will translate the scenario to a private DNS setting.

Following the DNS query journey, we have:

1. A user initiates a HTTPS request to a domain from a client. In this example, they are attempting to navigate to the blob endpoint of their storage account via the browser on a Virtual Machine (VM).

2. The VM does not understand domain names, so it asks Azure Provided DNS (which lives at IP address 168.63.129.16) to help.

3. Azure Provided DNS delegates the DNS query out to one of its many Azure DNS Resolver servers.

4. The Azure DNS Resolver utilises the public DNS service, by forwarding the DNS query out to one of the finite number of Public DNS Servers on the internet.

5. The Public DNS Server receives the request, and is able to look up the associated IP address for the domain in question. In this example, the IP address is 40.68.176.16. It returns this IP address to the Azure DNS Resolver.

6. The Azure DNS Resolver passes this IP address back to Azure Provided DNS.

7. Azure Provided DNS provides the IP address to the VM.

8. The VM now knows where to take the user to, and can navigate to the blob public endpoint of the storage account in question.

So now we understand how public DNS works, but how does this work in a private network setting? The answer is in the name of Step 5: Private DNS Zones!

What is an Azure Private DNS Zone?

An Azure Private DNS Zone is an Azure resource. It’s known as a global resource, and is therefore not tied to a specific region. It is expected that Private DNS Zones are centralised, and therefore often live in the hub. Think of a Private DNS Zone as a private phonebook; similar to the contacts list in your phone, compared to the public phonebook.

Let’s look at how the addition of an Azure Private DNS Zone resource changes our DNS query journey.

Private DNS

Since we are now working in a private network setting, we need to make a few changes to our architecture. We now have a Virtual Network (VNet), and have assigned a Private Endpoint to our Storage Account (for the blob sub-resource type), the IP address of which belongs to the VNet. The VM now also sits inside the VNet, since we can only access Private Endpoints from within the private network itself.

Legs 1, 2 and 3 of the DNS query journey are the same as before. So let’s pick up there:

4. The Azure DNS Resolver receives the DNS query for the blob endpoint domain, but instead of sending this request out to a Public DNS Server, it tells Azure Provided DNS that a new DNS query needs to be initiated, and the domain in question has “privatelink” inserted into it. It’s as if the Azure DNS Resolver is aware of a mapping between the default public domain and the private link version of the domain (more on this later!).

5. Azure Private DNS then initiates a new DNS query for the private link domain. The addition of privatelink into the domain name changes the destination DNS server that the query is now sent to. Instead of the query being sent to an Azure DNS Resolver (which sits on the Microsoft backbone network), it is now sent to a Private DNS Zone which is accessible from your private network (again, more on this later!). Crucially, the Private DNS Zone resource must be named after the domain for which it resolves queries for. In this example, the domain (and therefore the name of the Private DNS Zone) is privatelink.blob.core.windows.net.

6. If the Private DNS Zone contains an associated private IP address for the domain in the DNS query, it will return the IP address to Azure. In this example, the private IP address is 10.0.0.8. This is the IP address of the Private Endpoint.

7. Azure DNS will then send this information back to the VM.

8. The VM now knows that when we ask it to navigate to the blob endpoint of our storage account, to take us to the IP address 10.0.0.8. Our VM is inside the same network as this Private Endpoint, and so it has access.

This completes the DNS query when using Private DNS.

Azure Private DNS Zone Naming

As mentioned leg 5 of the DNS query journey, the name of the Azure Private DNS Zone must be named after the domain for which it resolves queries for. Some exaples are:

A full list of Private DNS Zone names can be found here.

Step 5 Summary

Now we understand the role Azure Private DNS Zones play when using Azure Private Endpoints. However, there were two important steps that we glossed over in our early DNS journey:

1. How do we ensure the Private DNS Zone contains the associated private IP address for our domain?
2. How do we ensure that the Private DNS Zone is accessible from our private network in the first place?

You may have guessed that the answers to these two questions bring us to steps 6 & 7.

Step 6: A Records

DNS Records are the instructions that live in the DNS Servers on how to handle DNS queries for a particular domain. There are lots of types of DNS Records; A Records are a specific type of DNS Record that contain a domain’s associated IP address or addresses. You only need 3 pieces of information to populate them:

1. The record type (in this case, A),
2. The domain,
3. The IP address (or addresses).

The analogy we used earlier, comparing a Private DNS Zone to the contacts list in your phone, extends here. When you get a new SIM card, your contacts list is empty, and you must populate it with records which map a person’s name to their phone number. It is the same with Private DNS Zones; we must add in records which map our domains to our IP addresses.

Therefore, for any Private Endpoints you deploy, you must ensure you have an associated A Record in the relevant Private DNS Zone. There are automatic ways to create A Records for Private Endpoints upon deployment, however it is often likely that you will not have sufficient permissions over the Private DNS Zones to perform this automatic integration. In this situation, be aware that you will need someone to manually add the A Records for you.

Side Note: CNAME Records

As an aside, we noted earlier that when a Private DNS Zone exists, Azure DNS is re-routed to the Private DNS Zone instead of the Public DNS Server, as if it is aware of a mapping between the default public domain and the privatelink version of the domain. This is because when a Private DNS Zone is created for a particular domain, another type of DNS Record is created inside the Azure DNS Resolvers called a CNAME Record. A CNAME Record maps one domain to another domain, and that’s how Azure DNS knows to re-route the DNS query to the Private DNS Zone.

Step 7: Virtual Network Links

By default, VNets are not aware of Private DNS Zones, so any client (e.g. a VM) inside the VNet cannot use the zones to look up IP addresses. We must explicitly connect VNets to Private DNS Zones, and this is called a VNet Link. Once a VNet is linked to a Private DNS Zone, any client within that VNet can successfully send DNS queries to the zone.

This is how we ensure that our Private DNS Zone is accessible from our private network. It may be that you need to add VNet Links for multiple networks to your Private DNS Zones. For example, if you want to resolve your Private Endpoints from on-premise, you will likely need to add a VNet Link for your hub network, since this will likely be where your on-premise traffic comes into Azure.

7 Step Process Summary

1. Private Endpoint Resource: You must deploy a standalone resource for anything you want to use a Private Endpoint for;
2. Coupled Azure Resource: You must tell each Private Endpoint which coupled Azure resource you are wanting to use it for;
3. Target Sub-resource: You must tell each Private Endpoint which specific service of a resource you want to replace;
4. Virtual Network (IP Address): A Private Endpoint is essentially a Private IP address, therefore you must tell the Private Endpoint which VNet it should assign an IP address from;
5. Private DNS Zone Resource: A Private DNS Zone resource is required for each sub-resource type you use Private Endpoints for;
6. A Record: Every Private Endpoint needs an A Record inside the relevant Private DNS Zone;
7. Virtual Network Link: For every network that you want to resolve Private Endpoints from, you must have a VNet Link on every relevant Private DNS Zone.

Hopefully this 7 Step Process will help you to confidently and successfully configure and deploy you own Azure Private Endpoints.