Hello.
I wanted to try the azure dns private zones (https://docs.microsoft.com/en-us/azure/dns/private-dns-getstarted-cli) (it is in preview now) and I am getting this err:
"The subscription is not registered for the resource type 'dnszones' in the location 'westeurope'. Please re-register for this provider in order to have access to this location."
I use azure-cli (2.0.30) on Mac installed via curl/bash.
The subscription is registered under Microsoft.Network provider.
Wha I am missing?
Thank you very much
Hi Trepliev,
I had the same issue recently but I got this fixed by changing the location to 'global' instead of 'westeurope'. This is because Azure DNS is a global service.
Hope this helps :)
@Trepliev , @averhaegen . What command resulted in this error?
Hi, I have had the same issue with my MSDN subscription, I've issued the following command:
az network dns zone create -g $RESOURCE_GROUP -n contoso.com
And I got this exact same error, using latest az cli
@ernani what was the exact command you used? What location was your resource group in?
@tjprescott The command I issued is outlined in the previous thread, the resource group is in ~eastus2~ eastus In my case, the error relates to ~eastus2~ eastus as well, not like this one that states westus.
Does it work if you use --location global?
I've tried that before as per @averhaegen 's suggestion and I get the following error:
az: error: unrecognized arguments: --location global
@ernani @adewaleo I created the DNS using an ARM Template. I got this error because I used the same location as my Resource group. But after setting the location to global, the deployment succeeded.
It seems Microsoft should update the azure cli to accept a 鈥攍ocation parameter when creating a DNS
@averhaegen I have had to create mine via portal, then it worked. It seems it is just a need to allow --location to be global or hardcode it, and ignore whatever the user specifies if they do but, I am knot sure how az cli global parameters would rule it out. That's just my guess.
In my case, the problem was that I had set my default location (using az configure), so it tried to use that one instead of "global". Once I removed my default location, I could create a DNS zone without getting an error. Since you can't pass a location parameter to the "az network dns zone create" command, there's no other way to do it, but that command really shouldn't be reading your default location. Microsoft needs to fix this.
@guyhummel Nice catch, that's exactly my own case here.
@guyhummel , I will work on a fix of this issue. You are right that the command should not use the default location when it doesn't expect the user to provide one.
Thanks for your incredibly fast response! I'm looking forward to seeing this work when you push the fix to production.
You are welcome!