dmauser/PrivateLink

On-Premise Trying to resolve public IP.

jaydesai-automate opened this issue · 3 comments

jaydesai-automate commented

Hello, Thank you for this article, it was very useful. Maybe more of a question than an Issue.

Here is the scenario. I Have a similar setup as you explained in your article, 4.1 Azure DNS Private Resolver (Preview) (https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios#4-on-premises-dns-integration) I have a conditional forwarder on your on-premise DNS to blob.core.windows.net.

In this architecture, the following will work.

  1. A Storage account with No Private Endpoint, on my tenant or any other tenant. ( You will get the Public IP as expected)
  2. A Storage account with a Private Endpoint, on your tenant, and an A record in your Private DNS Zone. (You will get the Private IP from your tenet as expected)

This does not work.

  1. A Storage account with a Private Endpoint enabled that is not on your tenant and allows your public IP to connect via Public Network. (Your Azure DNS Private Zone, does not have an entry for it, so it does not respond with any IP, ideally, it should return the Public IP Address associated with this storage account)

In this case, users in your company who want to connect to this storage account would need to edit their host files, or we would have to create a record in our Azure DNS Private Zone, to the public IP Address.

Is this a correct understanding and outcome of this? Anyway, around this case?

Thank You,
Jay

chboudry commented

If the private IP does not belong to you & your zone, you will get the public IP automatically

dmauser commented

@jaydesai-automate, that is a side effect because you become authoritative of the privatelink.blob.core.windows.net, and when you try to resolve a storage account that is in another tenant and it is going to fail. Have you seen this post related to this behavior?
https://github.com/dmauser/PrivateLink/tree/master/Issue-Customer-Unable-to-Access-PaaS-AfterPrivateLink

jaydesai-automate commented

@jaydesai-automate, that is a side effect because you become authoritative of the privatelink.blob.core.windows.net, and when you try to resolve a storage account that is in another tenant and it is going to fail. Have you seen this post related to this behavior? https://github.com/dmauser/PrivateLink/tree/master/Issue-Customer-Unable-to-Access-PaaS-AfterPrivateLink

Thank you @dmauser This is it. I just was not sure this was the case, but the article did confirm the exact thing I was asking about. Thanks.