Azure DNS Resolver Cannot resolve another vnet's private link resources to public ip.
Azure DNS Resolver Cannot resolve another vnet's private link resources to public ip.
so I cannot use the storage account in the vm of using dns resolver. DNS Resolver cannot query Private Link resources's public ip.
the storage account's firewall is "allow all"
Is it by design?
I wanna use other private link services by public ip.
how can I use this?
See the Arch.
Azure DNS
Azure Private Link
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-08-29T10:36:47.3+00:00 Hello @최 규호 ,
Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.
Azure DNS Private Resolver is a new service that enables you to query Azure DNS private zones from an on-premises environment and vice versa without deploying VM based DNS servers.
Refer: https://video2.skills-academy.com/en-us/azure/dns/dns-private-resolver-overview
And a private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that's powered by Azure Private Link. By enabling a private endpoint, you're bringing the service into your virtual network.
Refer: https://video2.skills-academy.com/en-us/azure/private-link/private-endpoint-overview
So, why would you like to use private link services by public IP and DNS Resolver to query Private Link resources public IP?
If you would like to access the Storage account publicly, then the use of Azure DNS Private Resolver and Private endpoint doesn't make sense for your setup.
What is your exact requirement?
Regards,
Gita
-
최 규호 91 Reputation points
2023-08-30T00:48:06.1566667+00:00 you can see the arch.
the detail situation is that.
One customer use storage account by private link service.(tenant1)
the other customer use private dns resolver.(tenant2)
and tenant2 customer need to use tenant1's storage account.
so tenant1 customer open the storage account firewall allow all.
but the tenant2 user cannot query the tenant1's storage.
you can understand?
thank you
-
최 규호 91 Reputation points
2023-08-30T01:56:42+00:00 and today's test, private dns resolver can query without private dns zone but if you have private dns zone of the vnet link. than cannot query the another vnet's storage account.
thank you.
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-08-30T15:45:03.4966667+00:00 Thank you for the update, @최 규호 .
This is a by design behavior as mentioned in the below doc:
Private networks already using the private DNS zone for a given type, can only connect to public resources if they don't have any private endpoint connections, otherwise a corresponding DNS configuration is required on the private DNS zone in order to complete the DNS resolution sequence.
The only solution that I can think of is to manually add a DNS record to point to the Public IP of the storage account in DNS zone of Tenant 2.
Like the below screenshot:
Could you please give this a try and let me know if it works?
Regards,
Gita
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-09-07T15:30:51.1366667+00:00 Hello @최 규호 , could you please provide an update on this issue?
-
최 규호 91 Reputation points
2023-09-22T00:59:27.2133333+00:00 hi @GitaraniSharma-MSFT Im sorry to late.
It works. but there was some problem.
if the ip address of azure stroage account is change, the storage cannot connect it.
I know the storage account cannot assign the static public ip.
how to solve it? Use the Cname of Storage account?? the Cname "blob.se1prdstr06a.store.core.windows.net" is static?
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-09-25T08:05:39.03+00:00 @최 규호 , thank you for the update. Let me check this and get back to you.
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-10-11T12:01:20.5733333+00:00 Hello @최 규호 ,
Apologies for the delay in response.
I discussed this with the Azure Storage team and then also reached out to the Azure Storage Product Group team and they mentioned the below:
You should not take a dependency on the CNAME to be the same always. This name blob.se1prdstr06a.store.core.windows.net can change when we load balance behind the scenes.
So, looks like you cannot use this CNAME as it might change.
Regards,
Gita
-
최 규호 91 Reputation points
2023-10-13T08:32:18.2033333+00:00 Hello @GitaraniSharma-MSFT
Then, the IP or CNAME Addresses are both can change?
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-10-13T13:14:43.8433333+00:00 @최 규호 , yes, that is correct. I'm still checking with the Azure Storage Product Group team if there is any other way to work around this. Will keep you posted.
-
GitaraniSharma-MSFT 49,386 Reputation points • Microsoft Employee
2023-10-13T14:11:05.0833333+00:00 @최 규호 , looks like it is better not to use the IP or CNAME of the stampname of Storage as the PG says:
It will resolve while the storage account resides on that stamp (blz23prdstr05a) if it’s migrated, or load balanced it will of course get a new IP and stampname.
So, wanted to check how about we go with Vnet peering between Tenant 1 and Tenant 2 and use private endpoint instead to access the Storage account of Tenant 2?
Will that work for your setup?
Regards,
Gita
Sign in to comment