Azure Private Endpoints & DNS: what happens under the hood

Private Endpoints allow establishing connectivity, which occurs exclusively over the backbone Azure networks, without the requests ever emerging to the public Internet.

... or at least that's what they say.

There are multiple non-trivial steps required to enable it, and under the hood Azure is also performing some implicit configuration. It is easy to make a mistake in the configuration, which breaks connectivity. There are also some limitations, which could only be learned the hard way.

So, what is required to configure a Private Endpoint? And what each step actually imply?

Step 1: Create a Private Endpoint

This automatically creates a Network Interface Card (NIC) and connects it to the desired VNet. The NIC is assigned with a private IP from the range of the VNet.

💥 Important side effect: when the first Private Endpoint is created for a resource, then Azure automatically amends records in the public DNS.

🔗 DNS resolution before creating a Private Endpoint:

1. Resource hostname → CNAME record for the Service Endpoint (hostname of the actual hosting server, e.g., blob.ams23prdstr16a.store.core.windows.net).
2. Service Endpoint -> A record for the public IP of the hosting server.

🔗 DNS resolution after creating a Private Endpoint:

1. Resource hostname → CNAME record for privatelink.{resource hostname}.
2. privatelink.{resource hostname} -> CNAME record for the Service Endpoint.
3. Service Endpoint -> A record for the public IP.

⚠️ At this point, the target resource is already reachable via the private IP, but the hostname of the resource does not resolve to it yet.

Step 2: Create a Private DNS Zone

The name of the Private DNS Zone must match the type of the target resource — check out the table in the documentation to find out the correct one.

There can be only one Private DNS Zone of each type in the same Resource Group — as the name of the Zone is a part of the Resource ID.

Step 3: Link the Private DNS Zone to the desired VNet

One Private DNS Zone can be linked to multiple VNets.

One VNet can be linked only to one Private DNS Zone of each type.

Step 4: Register the Private DNS Zone under the Private Endpoint

... or, in Azure Portal terms: add the Private DNS Zone into a Private DNS Zone Group under the Private Endpoint.

💥 Important side effect: Azure automatically creates an A record in the Private DNS Zone for the private IP of the NIC of the Private Endpoint.

⚠️ It is impossible to add multiple Private DNS Zones of the same type into the same Private DNS Zone Group under a Private Endpoint (docs).

⚠️ It is impossible to add multiple Private DNS Zone Groups under a Private Endpoint (docs).

⚠️ It is possible to add only up to 5 Private DNS Zones into a Private DNS Zone Group under a Private Endpoint (docs).

Step 4 (alternative): Add A record manually

When any of the limitations above are hit, then the only way to enable the correct DNS resolution is to manually manipulate the Private DNS Zone.

It is possible to find out which private IP was assigned to the NIC of the Private Endpoint. Then, it is required to manually add an A record for this IP — thus, at last enabling the correct DNS resolution from inside the VNet.

🔗 DNS resolution after step 4 (see also an image in the docs):

1. (public DNS) Resource hostname → CNAME record for privatelink.{resource hostname}.
2. (private DNS)privatelink.{resource hostname} -> A record for the private IP.

The connectivity using the Private Endpoints is tricky, because it requires not only to connect resources to VNets, but also to establish the correct DNS resolution. For some of the steps, Azure is implicitly performing some configurations in the public global DNS — which is not trivial and is not really expected to happen. Then, there are other side effects and limitations of configuring the Private DNS Zone. At the end, it is still possible to link everything together and achieve connectivity which does not ever leave the backbone Azure networks.