azure-docs
azure-docs copied to clipboard
Confusion on Important Note for Private DNS Zones
In regards to the Important note "Existing Private DNS Zones tied to a single service should not be associated with two different Private Endpoints as it will not be possible to properly resolve two different A-Records that point to the same service. However, Private DNS Zones tied to multiple services would not face this resolution constraint." The first sentence of this statement is not making sense, as Private DNS Zones can be associated with multiple private endpoints . Did this mean to be worded as "A single service (i.e.. files) should not be associated with two different Private DNS Zones?"
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: a88af182-32aa-a8f3-359d-b92ae1cfb8c7
- Version Independent ID: 01ce07fc-4bc2-def5-9ecd-a80330ad9488
- Content: Azure Private Endpoint DNS configuration
- Content Source: articles/private-link/private-endpoint-dns.md
- Service: private-link
- GitHub Login: @asudbring
- Microsoft Alias: allensu
thanks for bringing this to our attention. I have assigned the issue to the content author to evaluate and update as appropriate
Any update on this? There is a similar message in the Azure Portal when adding a service to an existing zone.
A little bit confusing also for me.
I found this issue when goggling this message text to try and understand it. as it does not align with my understanding of Private DNS zones used for private endpoints. As stated by NebV it is entirely valid to have two A records for different endpoints
I'd like to know what I am being warned about, but I don't think adding a new record for private endpoint to an existing private dns zone is wrong.
If it were not seemingly impossible to do so in the portal I would wondered that this was a warning not to use a private dns zone for storage (i.e. privatelink.blob.core.windows.net) with a private endpoint you intend to use for a different type of service (i.e privatelink.vaultcore.azure.net) which makes a warning not to do this redundant.
Anyway, another vote for me on a better explanation here, if there is a risk here I'd like to know what it is.
Yeah i'm in the same boat, absolutely doesnt make sense to me
Yeah i'm in the same boat, absolutely doesnt make sense to me
Welcome on board of the confused community - waiting for rescue. ;-)
Also confused - does this mean you can't have two records in the same private dns zone pointing to two different endpoints for the same service? i.e you can't have two different records representing different blob storage endpoints but you could have say one pointing to file storage and one pointing to blob storage?
Sending to PM for review
#reassign:@ivapplyr
I assume this is about associating two Private Endpoints of the same service (e.g., two private endpoints of the same Event Hub Namespace) to single Private DNS Zone. Then, this Important Note from docs (the same message appears when you try to create a second private endpoint for the same service and associate it with single private dns zone) is correct as it won't be able to properly resolve these records.
hello, any updates? It still does not make sense, I have two vnets in two regions and a cosmosdb with multi-region access in those same two regions. I want to create private endpoints to the same cosmos service in both vnets. They will be associated with same Private DNS zone "privatelink.documents.azure.com" which is created in that resource group. What am I missing ?
Hi @yatish-wk thanks for the feedback.
What this is trying to say is that you can't have an Azure Private DNS zone configured with two private endpoint's DNS records for the same service. I think the last sentence is saying you can use one DNS zone with multiple services, but I'm not sure how that works because the zone is usually named the privatelink zone name for the individual services.
"I have two vnets in two regions and a cosmosdb with multi-region access in those same two regions. I want to create private endpoints to the same cosmos service in both vnets. They will be associated with same Private DNS zone "privatelink.documents.azure.com" which is created in that resource group. What am I missing?"
One CosmosDB Account with two private endpoints (One endpoint in one VNET and One endpoint in another VNET) using the same Azure DNS zone. There would be two IPs associated (one from each network) for the records in the zone. If you tie that zone to each VNET, then users in those VNets will sometimes get a resolution of the IP from the other VNET, therefore causing connection errors.
I will get some clarification on that last sentence and reword it. I can also get the portal changed if we change the verbiage in the article.
HI @asudbring, Thank you for your valuable response.
There would be two IPs associated (one from each network) for the records in the zone.
When I create first private endpoint in VNET1, there are three A records created in the private DNS zone (privatelink.documents.azure.com) with addresses from VNET1. Further when I create second private endpoint in VNET2, all three A records get replaced with addresses from VNET2. Now all users in both VNETs resolve cosmos name to VNET2 IPs only (not sometimes, but always).
What would be solution to resolve this issue? Thank you!
Hi @yatish-wk
One way to solve your issue would be to do a hub and spoke network with the private endpoint in the hub network and then your spoke networks are two way peered into the hub network. All of the networks use private resolver to resolve the centralized DNS records in Azure DNS. We have an article that is a similar configuration:
https://learn.microsoft.com/en-us/azure/private-link/tutorial-dns-on-premises-private-resolver
This article doesn't exactly have your scenario, but it's very similar. It has a "simulated" on premises network that you would replace with one of your VNets in your configuration.
@yatish-wk We have added an item in our backlog to update the verbiage of the note and get clarification on the last statement.
#please-close