Azure-docs: Multiple private endpoints and weird removal/rejection behavior

[rlevchenko]

Hi folks,

Imagine you have 1 storage account , 1 vnet with multiple subnets and decided to add 1 private endpoint to that storage account (10.3.1.4 ip , as shown in the picture below):

Then, you go to the private DNS zone and check the current A record for the endpoint to make sure that it's pointed to the just created endpoint:

Now you want for some reason to add the second endpoint to the storage account (10.3.1.8 ip):

And again we check the dns zone and notice that the record has been changed to the 10.3.1.8:

Then, you realize that don't need the first endpoint (10.3.1.4;) and have to remove it from the storage account page, so the second endpoint only remains. Surprisingly, the removal or rejection of the first endpoint also clears the dns zone and removes the endpoint A record regardless the fact it's pointed to the second endpoint's IP. Actually, it does not matter which endpoint you delete/reject* and what subnets/vnets they belong to. The behavior would be the same - no A records in the zone*:

So, the user is REQUIRED to control manually Azure private DNS zone in case of multiple endpoints. Now I have to add a record set back for the 10.3.1.4 endpoint, for example.

Is it expected behavior? I can't understand the logic behind all this : 1) the record always points to the last added endpoint 2) removal of any configured endpoints clears the DNS zone records for the endpoint. Is it just a way of maintaining a single IP in order to meet this "For a single network using a common DNS server configuration, the recommended practice is to use a single private endpoint for a given private link resource to avoid duplicate entries or conflicts in DNS resolution." ? However, I checked a multiple networks setup and got the same behavior...

I would like to see updated docs on that.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b006a616-2f2f-8ecf-8b80-fd0a3cc62090
• Version Independent ID: 92c54dc6-8ddf-b1f7-4a58-d61b8cd7fe25
• Content: What is an Azure Private Endpoint?
• Content Source: articles/private-link/private-endpoint-overview.md
• Service: private-link
• GitHub Login: @malopMSFT
• Microsoft Alias: allensu

[malopMSFT]

Thanks for the feedback

According to guidance, using 2 private endpoints on the same network (Vnet) and the same private DNS zone is considered a misconfiguration.

It's generally a bad practice for DNS to use the same domain to resolve to more than a single IP address when not necessary, it could lead to unpredictable behavior on the route traffic will take within the private network leading to potentially some firewall or NSG not allowing an specific path.

Complete details on the guidance is included here:
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns

[rlevchenko]

@malopMSFT yeah, I see. but it's not clear after reading the docs. It's the main point. There is just a recommendation "For a single network using a common DNS server configuration, the recommended practice is to use a single private endpoint for a given private link resource to avoid duplicate entries or conflicts in DNS resolution". Why can't I just reject (not removal!) endpoint without resetting the entire private zone? Can you please point me out a quote that prohibits "2 endpoints on the same vnet is a misconfiguration"? May be just a short "Important.." section in the docs would resolve any misunderstandings...or even new portal deployment template verification to prevent such configuration

P.S. I fully understand the limits/dns limits and etc..Talking about docs and what portal allows me to create and add..Some consistency is needed (my 2 cents..I might be wrong). Thanks.

[malopMSFT]

It's only a recommendation as we have a few customer's taking different approaches with different DNS servers on the same private network, those have custom handlers for resolution.

The quote is the same, basically DNS is a common area for a given domain.
"A single private DNS zone is required for this configuration. All client connections made from on-premises and peered virtual networks must also use the same private DNS zone."

[rlevchenko]

Got it. Thanks.