The architecture explanation is complex so read carefully I have a SQL server in East US region that I want other services to connect to privately, other services includes: AKS App services (both web and function apps) AKS is in West US 2 so I created a private endpoint of SQL server in West US 2 in the VNet of AKS for smooth communication between AKS and SQL Server, I can verify this communication by going to "Metrics" tab in the said private endpoint and it shows some spikes which means some communication is going through it. Now, I have app services in West US region, web apps are integrated to a VNet A and function apps are integrated to a VNet B; now to connect both of them to SQL privately, I needed to create two private endpoints in SQL and that's what I did. Now, the issue I face is that these app services are unable to connect to the SQL server privately, and I cannot see any spikes on the Metrics graph. I deployed a VM connected to VNet A, when I tried to nslookup the SQL's DNS name, it resolved to the public IP, after much troubleshooting I opened the Virtual Network Links in the Provaye DNS Zone of the database and it didn't contain the VNet A and VNet B but just AKS's VNet; I manually added VNet B and retired nslookup this time it resolved to a private IP address but the range was 172.x.x.x which is in VNet B, the private range in VNet A is 10.x.x.x, this is confusing now. Can someone explain me, what am I doing wrong? Ask me if you need more information.

@Najam ul Saqib , Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well. From your verbatim, I believe you are running into the below issue, Existing Private DNS Zones linked to a single Azure service should not be associated with two different Azure service Private Endpoints. This will cause a deletion of the initial A-record and result in resolution issue when attempting to access that service from each respective Private Endpoint. Create a DNS zone for each Private Endpoint of like services. Don't place records for multiple services in the same DNS zone . See : Caution | Azure Private Endpoint private DNS zone This is because a Private DNS Zone can not have multiple records with the same name. In your case, with the Private EndPoint of AKS VNET, let's say you have <YOURSQLServer>.database.windows.net -----> IP of PE in AKS VNET Now, this means you cannot have <YOURSQLServer>.database.windows.net -----> IP of PE in VNETA or <YOURSQLServer>.database.windows.net -----> IP of PE in VNETB I would suggest you create 3 separate Private DNS Zones to hold the record for each Private EndPoint, each having the PE IPs respectively Kindly let us know if this helps or you need further assistance on this issue. Thanks, Kapil Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Connection issues with multiple private endpoints for a single resource

Accepted answer

KapilAnanth-MSFT 47,206 Reputation points Microsoft Employee

2024-10-14T12:06:53.17+00:00
@Najam ul Saqib ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

From your verbatim, I believe you are running into the below issue,

Existing Private DNS Zones linked to a single Azure service should not be associated with two different Azure service Private Endpoints. This will cause a deletion of the initial A-record and result in resolution issue when attempting to access that service from each respective Private Endpoint. Create a DNS zone for each Private Endpoint of like services. Don't place records for multiple services in the same DNS zone.

See : Caution | Azure Private Endpoint private DNS zone

This is because a Private DNS Zone can not have multiple records with the same name.

In your case, with the Private EndPoint of AKS VNET, let's say you have

<YOURSQLServer>.database.windows.net -----> IP of PE in AKS VNET

Now, this means you cannot have

<YOURSQLServer>.database.windows.net -----> IP of PE in VNETA
or

<YOURSQLServer>.database.windows.net -----> IP of PE in VNETB

I would suggest you create 3 separate Private DNS Zones to hold the record for each Private EndPoint, each having the PE IPs respectively

Kindly let us know if this helps or you need further assistance on this issue.

Thanks,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.
Please sign in to rate this answer.

1 person found this answer helpful.
Najam ul Saqib 340 Reputation points

2024-10-14T13:55:34.27+00:00

@KapilAnanth-MSFT Your diagnosis of the problem is spot on, now to implement this I have few more questions:

I will create two more private DNS zones, the one that is already created, I will remove VNet A and VNet B from it and let the AKS VNet be the only entry in Virtual Network Links, right?

What name should I give to the private DNS zone? Obviously if I give the privatelink.database.windows.net it will throw error as it already exists, so will giving a new name have effect on the FQDN?

If I try to give "privatelink-2.database.windows.net" as name, it warns me "windows.net is an Azure infrastructure domain. Creating private DNS zones containing this name may have unintended consequences for DNS resolution for services deployed in your virtual networks." So what should be the naming convention here?

If I create multiple private DNS zones in same resource group, how will the app service know which one to consume?

I am assuming that by using multiple private DNS zones I will be able to use same FQDN for SQL server across the app services. One solution someone suggested me is to have different names in recordsets of one private dns zone pointing to their respective private IP, that will eventually mess up with the FQDN. Share your thoughts on this approach as well.

KapilAnanth-MSFT 47,206 Reputation points Microsoft Employee

2024-10-14T14:18:09.6366667+00:00

@Najam ul Saqib , Thank you.

1.I will create two more private DNS zones, the one that is already created, I will remove VNet A and VNet B from it and let the AKS VNet be the only entry in Virtual Network Links, right?

Correct

2.What name should I give to the private DNS zone? Obviously if I give the privatelink.database.windows.net it will throw error as it already exists, so will giving a new name have effect on the FQDN?

3.If I try to give "privatelink-2.database.windows.net" as name, it warns me "windows.net is an Azure infrastructure domain. Creating private DNS zones containing this name may have unintended consequences for DNS resolution for services deployed in your virtual networks." So what should be the naming convention here?

4.If I create multiple private DNS zones in same resource group, how will the app service know which one to consume?

All these issues would be resolved if you create the Private DNS Zone in a new Resource Group

I am not sure how you are compartmentalizing the resources,

if you are using different resource groups for different VNETs, then you can create separate private DNS Zones in the VNETs' RGs respectively

However, if all the resources are in the same RG so far, I am afraid you must create new resource groups for individual Private DNS Zones.

The third option, if all the VNETs are peered together,

You can simply use a single Private EndPoint

And hence, only a single Private DNS Zone is needed

However, I understand this depends on your architecture.

Wrt, "how will the app service know which one to consume?" - the VNET integrated App Service would use the Private DNS Zone which is linked to the VNET in which it is integrated.

5.One solution someone suggested me is to have different names in recordsets of one private dns zone pointing to their respective private IP

This isn't a right approach

You should not make connections to PaaS Services using different names other than the platform assigned end point FQDN

This is important for host name preservation and some PaaS Services may require SNI

Hope this helps.

Thanks,

Kapil

Please Accept an answer if correct.

Original posters help the community find answers faster by identifying the correct answer.

Najam ul Saqib 340 Reputation points

2024-10-14T15:56:48.31+00:00

@KapilAnanth-MSFT In my case, VNet A and B, private DNS Zone and all three private endpoints are in one resource group; whereas AKS's VNet is in a separate resource group. I would like to go with multiple DNS zones approach, but how should I structure this?

Najam ul Saqib 340 Reputation points

2024-10-14T16:02:26.3433333+00:00

One approach I have in my mind is that since Vnet A and B are in same region and resource group, I just merge them and their private endpoints.

For AKS, since its VNet is in a separate resource group, I should better move the private DNS zone of AKS and private endpoint to its own resource group; and utilize the current resource group for a new private DNS zone. What do you think?

KapilAnanth-MSFT 47,206 Reputation points Microsoft Employee

2024-10-15T08:46:31.89+00:00

@Najam ul Saqib,

Grouping resources by Region is a good approach as well.

When you say "merge them and their private endpoints" - I take it that you are either planning to peer the VNETs or use a single VNET with Private EndPoint in one of the VNETs.

i.e., you will have one PE per region

One used by VNETA and VNETB (located either in VNETA or VNETB)

One used by the AKS VNET

Resource groups are only logical grouping and they only store the metadata, you should be fine as long as you are able to categorize your resources in Azure (either by region/resource/project)

Thanks,

Kapil

Please Accept an answer if correct.

Original posters help the community find answers faster by identifying the correct answer.

Najam ul Saqib 340 Reputation points

2024-10-15T16:28:40.8133333+00:00

I was able to solve the issue, here's how:

In the resource group that was hosting VNet A and VNet B, I realized that we dont actually need two different VNets, so I deleted VNet B and integrated VNet B's app services to VNet A, now I have VNet A as the only VNet in this RG

Since a single resource group cannot have multiple private DNS zones pointing to same service, so I noticed that the VNet of AKS is in another RG lets call it "AKS VNet" and other one "App service VNet". App service's VNet was having private endpoint of AKS VNet and private DNS zone in it, so I moved these two resources to AKS's VNet and that's how I was able to move one of the private DNS zone to a separate RG

Now I was having two private DNS zones in the App Service's VNet and two private endpoints, and since I removed one VNet so technically I dont needed one private endpoint and DNS zone that was linked with VNet B, therefore I deleted both of these resources as well.

As a result I was having one private DNS zone, one private endpoint and one VNet in App service's VNet and similar one set in AKS's VNet and everything worked well. Huge thanks to @KapilAnanth-MSFT for his assistance.

KapilAnanth-MSFT 47,206 Reputation points Microsoft Employee

2024-10-16T03:42:20.5233333+00:00

@Najam ul Saqib,

Glad we could be of assistance :)

Thanks for your continued contribution on Q&A and appreciate much for taking the time to share your feedback

Cheers,

Kapil
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Connection issues with multiple private endpoints for a single resource

0 additional answers

Your answer