Name resolution is an important part in the Azure Stack solution. When tenants create storage accounts, web apps and virtual machines they might want to expose these services to their users via the intranet or internet. Once you have deployed Azure Stack you have DNS the following way:

• <regionname>.<fqdn> (as an example: bellevue.asic.cloud)

That creates portal URL’s, ARM, KeyVault and storage endpoint all under that particular namespace. There is one exception for public IP’s that you attach to load balancers or directly on NIC’s attached to the VM. That will create a record as following:

• <MyCustomLabel>.<region>.cloudapp.<fqdn> (as an example: myvm01.bellevue.cloudapp.asic.cloud)

So what’s the deal here?

If you have delegated the whole <fqdn> zone to the Azure Stack nameservers, not so much. But if you have delegated sub zones to Azure Stack it actually is. The way how we have done is by delegating <region>.<fqdn> to nameservers deployed in the Azure Stack stamp. This is how it looks like in my DNS zone that I hosted in public Azure:

 

You can retrieve the ip and names information in the AzureStackStampInformation.json after the deployment of Azure Stack. Your OEM should hand that over to you. 1 other way is to retrieve it from the PEP endpoint.

“ExternalDNSFQDN01”:  “AzS-ns01.bellevue.asic.cloud”,

“ExternalDNSFQDN02”:  “AzS-ns02.bellevue.asic.cloud”,

“ExternalDNSIPAddress01”:  “65.152.9o.77”,

“ExternalDNSIPAddress02”:  “65.152.9o.78”,

But what is missing is that additionally you need to delegate also the <region>.cloudapp.<fqdn> to these name servers:

This is what it looked liked after I added the record:

Now when tenants configure names for their public IP attached to load balancers or VM’s the record will be able to resolved from internet or intranet.