Azure Private Link has been available in Azure little bit over year now. It was published 16.9.2019 to Public Preview. 14.2.2020 it got it General Available (GA) status and after that there have been added many PaaS-services for it. In short, Azure Private Link connects your PaaS service such as SQL Server, Storage account or App Service to your subnet and gets a private IP for it. It uses resource called private endpoint to accomplish it. Then you need some DNS-configurations and everything works like a magic. I’ve seen that this isn’t so clear for everyone how private endpoints works so I’d like to clarify it little bit more.

When implementing Azure Private Link, remember always use the public facing name for applications to reach the resource. DNS handles rest.

Azure Private Link as a concept

When you create a private endpoint (the resource that is used in the Private Link -concept), you will change the public name resolution for the resource towards you are creating the private endpoint. Let’s look little bit that. I have a storage account called bloggerzstorage and it has a public IP address provided by Azure.

Storage account public IP address from Azure without private link alias
Public IP from Azure without private link alias

Enabling Azure Private Link

When I create a private endpoint, Azure is changing the public name resolution by adding there another CNAME record pointing towards the dedicated FQDN of private endpoint. The record name and zone depends of resource type (or sub-type) and you can find the reference of DNS zone naming from the Microsoft’s documentation. For the storage account’s blob sub-resource as in this example the FQDN will be <storage-account-name>.privatelink.blob.core.windows.net.

Storage account public IP address from Azure with private link alias
Public IP from Azure with private link alias

DNS-record for Azure Private Link

Currently the IP that your DNS is resolving is the public IP, because there isn’t anything available in private link CNAME.

Now you should add to your internal name resolution an A-record that points the private endpoint address to the private IP that is associated for the resource inside your Azure virtual network:

Private DNS zone with a record
DNS-record in Internal DNS zone

When you try to resolve it now from the client that is using the internal DNS-server, it will response the private IP address.

Storage account public IP address from Azure with private link alias and internal IP
Private IP from Internal DNS

How this is possible then? It’s not magic. Azure’s public DNS servers (where e.g. blob.core.windows.net is hosted) is configured to prioritize privatelink.blob.core.windows.net if available. According to RFC’s 1912 paragraph 2.4 multiple CNAME’s isn’t encouraged. But it works. For prioritizing records, you can consult RFC 1035 paragraph 7.2, but as you know, the DNS server hoster can do what ever she wants.

And as a conclusion Private link address will be prioritized in name resolution.

Private DNS zone resource

In next chapter I’m telling my best practices to implement DNS resolution in different scenarios. Before that I’m introducing a resource from Azure called Private DNS zone. It’s a private DNS zone that can be only accessed from Azure backend. Not from internet, only behind the Azure’s public IP addresses.

Private DNS Zone
DNS queries allowed from Virtual Network not from Internet

You can create required private link DNS zone e.g. privatelink.blob.core.windows.net to there and use it from Azure. When creating a private endpoint, you can tell also to automatically add the A-record to the private DNS zone. Azure engineer does not need to have access to your DNS-infrastructure e.g. in Windows Server Active Directory. Also when you are deleting the private endpoint, the A-record is removed automatically when using Azure Private DNS Zones. Sounds nice? YES!

Name resolution options

There are several ways to achieve the name resolution, but I will now tell how I would implement it. Normally you have three options depending of your infrastructure:

  • Azure VNET without custom DNS Servers (without Active Directory)
  • On-premises and/or cloud workloads with own DNS servers (e.g. with Active Directory) and multiple internet routes
  • On-premises and/or cloud workloads with own DNS servers (e.g. with Active Directory) and internet gateway forced in on-premises

Azure VNET without custom DNS Servers (without Active Directory)

This is the most straight forward scenario. Just create a Private DNS Zone to Azure named by domain name that is going to be the private endpoint domain name for your resource for example privatelink.blob.storage.windows.net.

When creating the private endpoint, just select the dedicated zone for automatic DNS registration and all configured.

If the request to the public DNS-name (bloggerzstorage.blob.core.windows.net) is coming from VNet the Private DNS Zone answers the private endpoint’s internal IP, but if the request is coming from internet, the Azure’s own DNS answers the public IP.

Azure VNET without custom DNS Servers (without Active Directory)
Private endpoint in Azure public DNS service
  • VM asks the public name bloggerzstorage.blob.core.windows.net
  • Private DNS Zone Answers to request through Azure DNS
  • VM connects to Private Endpoint
  • DNS requests not allowed from internet
  • You access storage account with a public IP provided by Azure

Remember always use the public facing name for applications to reach the resource. DNS handles rest.

On-premises and/or cloud workloads with own DNS servers (e.g. with Active Directory) and multiple internet routes

So if you have a route to the internet available on Azure you can also use Private DNS zones. You can route some of your internal networks to the internet from some other point (for example from on-premises datacenter), it really doesn’t matter. You have same benefits when having a full name resolution on Azure services. When you create a private endpoint, you can have an automatic DNS record creation to your Private DNS zone and it works.

In this scenario you have your own DNS Servers such as a Windows Server Active Directory integrated DNS that you want to use for name resolving. To get the name resolving working, install DNS servers also to the cloud. Without some server that acts as a DNS relay in the VNet, your DNS traffic is not routed to the internet (and Private DNS Zone) from Azure. After you have the relay server, just create a conditional forwarder to on-premises DNS for your private link zones and point those towards your Azure VM which is a DNS relay in cloud. Remember to put forwarders also for Azure DNS server to point Azure’s public DNS services in IP 168.63.129.16. You can use for example couple of domain controllers in cloud to act as a DNS relay.

Conditional forwarder
Conditional Forwarder in on-premises DNS Server

DNS request that is asked from Azure DNS Services must be routed through some Azure Virtual Network, otherwise it is not allowed to Azure Private DNS zones. For lower latencies I suggest that you use your ISP provided DNS as a forwarder in on-premises DNS servers and Azure public DNS services in Azure based DNS servers. Ensure that always, when some VM tries to reach Azures DNS service 168.63.129.16 (also from on-premises), the traffic must be routed through the Azure Virtual Network through the DNS relay. You can do this with a route table in Azure and on-premises firewall or what ever you are using as a routing device in on-premises.

Remote DNS requests relayed through azure
DNS Relayed through server in Azure
  • VM asks the public name bloggerzstorage.blob.core.windows.net from local DNS server
  • DNS Server forwards the request with conditional forwarder to Azure DNS that asks it from Azure’s public DNS servers and the DNS servers responses the private IP to the client
  • DNS server responds the private IP to client
  • VM connects to Private Endpoint
  • DNS requests not allowed from internet
  • You access storage account with a public IP provided by Azure
  • Use your local ISP DNS as a forwarder for other DNS queries

Remember always use the public facing name for applications to reach the resource. DNS handles rest.

On-premises and/or cloud workloads with own DNS servers (e.g. with Active Directory) and internet gateway forced in on-premises

The last scenario is if your default route points to the on-premises and all traffic is routed to the internet from there (the legacy way). In this scenario you can’t use Azure Private DNS Zones since you can’t access them from the internet. Instead you have to create own DNS-zones to your DNS Server Infrastructure. In this scenario select no when private endpoint creation provides the ability to add a A-record to the Private DNS zones as there isn’t one.

Every time you are creating a private endpoint you have to manually add an A-record to your DNS and remove the record when removing the private endpoint. Of course you could create a script that for example uses Azure Event Grid to catch Private Endpoint creation or removal and modify DNS entries to the on-premises DNS servers, but is it clever? Avoid this, but it’s doable.

On-premises and/or cloud workloads with own DNS servers (e.g. with Active Directory) and internet gateway forced in on-premises
Default route to on-premises. Azure internet not in use.
  • VM asks the public name bloggerzstorage.blob.core.windows.net from local DNS server
  • DNS Server answers locally from own privatelink.blob.core.windows.net zone the private IP
  • VM connects to Private Endpoint
  • You access storage account with a public IP provided by Azure
  • Use local ISP DNS for public name forwarding

Remember always use the public facing name for applications to reach the resource. DNS handles rest.

Private DNS Zone in different subscription?

You can have a Private DNS Zone also centrally in different subscription and just delegate proper permission to it. To manage A-records in Azure Private DNS zone you read in minimum Microsoft.Network/privateDnsZones/A/* permissions.

When using auto registration of DNS name to Private DNS Zone, just select the correct subscription before selecting the DNS zone.

Subscription selection when creating a private endpoint.

Conclusion

Three different scenarios, three different ways to implement a DNS name resolution for a private link service. Hopefully this clarifies at least some ones mind how does private link and DNS work together and how mission critical it is.


Markus Lintuala

I've been working in IT since 2009 in different roles mostly with solution architecture, service development, training and consultancy side. With Azure I started to work in 2013 and with Microsoft 365 related products in 2011. I like to work often with the newest technologies by testing, giving feedback and share the knowledge to people around me. Currently I'm working much in Azure side with governances, security and solution architectures and in Microsoft 365 side with E5 security solutions with strong zero trust aspect.

2 Comments

Oliver · 04.01.2021 at 14.31

Hi MArkus,

great summary….
We are currently using the last scenario with different Private Zones configured on an onpremise DNS.
That all worked pretty good until we now want to connect to a DB from an external company which also uses privatelink-FQDNs.
So the first Cname comes back from the uplink DNS, but then the onpremise DNS checks his local zone and if there is no dedicated entry and the resolving process stops…
Or is there any fancy option in DNS I have missed so far, that checks the uplink DNS even if there is a .privatelink.[Azure-Service] – Zone configured..

Thanks in advance for your help,
Oliver

    Markus Lintuala · 08.01.2021 at 13.40

    DNS takes always the closest option available. If the zone exists in your own DNS server, it does not look up it anywhere else. So if you don’t have a record in zone it will not be resolved for client.

    You can create a private link also between tenants if you want to publish your DB from your home tenant to the external tenant without any VPN tunnels etc. Remember that you can’t monitor the access to DB on the network level in your tenant. When creating a private endpoint for external tenant, you have to manually approve it before it works in the external company. After it has been approved they can add a new A-record to their DNS and magic happens. 😉

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.