Use iDNS in Azure Stack Hub

iDNS is an Azure Stack Hub networking feature that enables you to resolve external DNS names (for example, It also allows you to register internal virtual network names. By doing so, you can resolve virtual machines (VMs) on the same virtual network by name rather than IP address. This approach removes the need to provide custom DNS server entries. For more information about DNS, see the Azure DNS Overview.

What does iDNS do?

With iDNS in Azure Stack Hub, you get the following capabilities, without having to specify custom DNS server entries:

  • Shared DNS name resolution services for tenant workloads.
  • Authoritative DNS service for name resolution and DNS registration within the tenant virtual network.
  • Recursive DNS service for resolution of internet names from tenant VMs. Tenants no longer need to specify custom DNS entries to resolve internet names (for example,

You can still bring your own DNS and use custom DNS servers. However, by using iDNS, you can resolve internet DNS names and connect to other VMs in the same virtual network without needing to create custom DNS entries.

What doesn't iDNS do?

iDNS doesn't allow you to create a DNS record for a name that can be resolved from outside the virtual network.

In Azure, you have the option of specifying a DNS name label that is associated with a public IP address. You can choose the label (prefix), but Azure chooses the suffix, which is based on the region in which you create the public IP address.

Example of a DNS name label

As the previous image shows, Azure will create an "A" record in DNS for the DNS name label specified under the zone The prefix and the suffix are combined to compose a fully qualified domain name (FQDN) that can be resolved from anywhere on the public internet.

Azure Stack Hub only supports iDNS for internal name registration, so it can't do the following things:

  • Create a DNS record under an existing hosted DNS zone (for example, local.azurestack.external.)
  • Create a DNS zone (such as
  • Create a record under your own custom DNS zone.
  • Support the purchase of domain names.

Demo of how iDNS works

All of the host names for VMs on Virtual Networks are stored as DNS Resource Records under the same zone, however under their own unique compartment defined as a GUID that correlates to the VNET ID in the SDN infrastructure that the VM was deployed against. Tenant VM Fully Qualified Domain Names (FQDNs) consist of the computer name and the DNS suffix string for the Virtual Network, in GUID format.

Following is a simple lab to demonstrate how this works. We've created 3 VMs on one VNet and another VM on a separate VNet:

VM vNet Private IP Public IP DNS Label
VM-A1 VNetA VM-A1-Label.lnv1.cloudapp.azscss.external
VM-A2 VNetA VM-A2-Label.lnv1.cloudapp.azscss.external
VM-A3 VNetA VM-A3-Label.lnv1.cloudapp.azscss.external
VM-B1 VNetB VM-B1-Label.lnv1.cloudapp.azscss.external
VNet GUID DNS suffix string
VNetA e71e1db5-0a38-460d-8539-705457a4cf75 e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local
VNetB e8a6e386-bc7a-43e1-a640-61591b5c76dd e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local

You can do some name resolution tests to better understand how iDNS works:

From VM-A1 (Linux VM): Looking up VM-A2. You can see that the DNS suffix for VNetA is added and the name is resolved to the Private IP:

carlos@VM-A1:~$ nslookup VM-A2
Non-authoritative answer:
Name:   VM-A2.e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local

Looking up VM-A2-Label without providing the FQDN fails, as expected:

carlos@VM-A1:~$ nslookup VM-A2-Label
** server can't find VM-A2-Label: SERVFAIL

If you provide the FQDN for the DNS label, the name is resolved to the Public IP:

carlos@VM-A1:~$ nslookup VM-A2-Label.lnv1.cloudapp.azscss.external
Non-authoritative answer:
Name:   VM-A2-Label.lnv1.cloudapp.azscss.external

Trying to resolve VM-B1 (which is from a different VNet) fails as this record does not exist on this zone.

carlos@caalcobi-vm4:~$ nslookup VM-B1
** server can't find VM-B1: SERVFAIL

Using the FQDN for VM-B1 doesn’t help as this record is from a different zone.

carlos@VM-A1:~$ nslookup VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local
** server can't find VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local: SERVFAIL

If you use the FQDN for the DNS label, then it resolves successfully:

carlos@VM-A1:~$ nslookup VM-B1-Label.lnv1.cloudapp.azscss.external
Non-authoritative answer:
Name:   VM-B1-Label.lnv1.cloudapp.azscss.external

From VM-A3 (Windows VM). Notice the difference between authoritative and non-authoritative answers.

Internal records:

Default Server:  UnKnown
> VM-A2
Server:  UnKnown
Name:    VM-A2.e71e1db5-0a38-460d-8539-705457ª4cf75.internal.lnv1.azurestack.local

External records:

> VM-A2-Label.lnv1.cloudapp.azscss.external
Server:  UnKnown
Non-authoritative answer:
Name:    VM-A2-Label.lnv1.cloudapp.azscss.external

In short, you can see from the above that:

  • Each VNet has its own zone, containing A records for all private IP addresses, consisting of VM name and the DNS suffix of the VNet (which is its GUID).
    • <vmname>.<vnetGUID>.internal.<region>.<stackinternalFQDN>
    • This is done automatically
  • If you use Public IP addresses, you can also create DNS labels for them. These are resolved like any other external address.
  • iDNS servers are the authoritative servers for their internal DNS zones, and also act as a resolver for public names when tenant VMs attempt to connect to external resources. If there is a query for an external resource, then iDNS servers forward the request to authoritative DNS servers to resolve.

As you can see from the lab results, you have control over what IP is used. If you use the VM name, you will get the private IP address and if you use the DNS label you get the public IP address.

Next steps

Using DNS in Azure Stack Hub