In this blogpost I will try to explain what iDNS is and how it is implemented in the latest technical preview Azure Stack. iDNS is a name resolution service for virtual networks where tenants don’t want to build and maintain their own DNS infrastructure. It allows VM’s to have name resolution to internet addresses as well as other VM’s in the same virtual network. The iDNS feature is a multitenant solution provided by Azure Stack and in the next section I will explain how it is implemented.

iDNS is existing of 2 parts. You will have an iDNS Server part and a iDNS proxy part.

Complete overview of iDNS in Azure Stack (source:technet.microsoft.com)

iDNS Proxy

iDNS Proxy is a service called DNSProxy. Each Hyper-V host has its own iDNS Proxy Service and NCHostAgent service running. So how does the service know about my network and when it is using custom DNS records or using the iDNS service?

When you log in to the portal and create a virtual network you have the option under ‘DNS Servers’ to select ‘Azure DNS’ or ‘Custom DNS’ servers. That’s the flipping bit for choosing between your own DNS servers (that you have to specify) or using iDNS service in Azure Stack. I showed here an example of an already deployed VM and the setting for using iDNS. This reference is used throughout the blogpost. So here my DEMOVM001 with network interface demovm001792 has selected the Azure DNS setting:

When I connect to this VM and look at the settings in my VM I noticed the following. I can ping bing.com and when I retrieve my DNS server that has been set by the deployment I noticed the DNS Server address 168.63.129.16:

So how this address I being actually used by my VM when doing a name lookup? When I log in to my Hyper-V host I see that the NCHostAgent has for the DNSProxyService the IP Address 168.63.129.16. It has attached the MAC 22-22-22-22-22-22:

This is the metadata service (MDS/GAR) hosted inside the NCHostAgent and this key you see above is used in the VFP to redirect the DNS requests to these DNS server defined in the DnsProxy service:

So my guess is that in the SDN stack, when I choose for AzureDNS, it flips a bit and add this record in my Route/Lookup table to allow the actual name resolution query for my VM.

So that was the iDNS Proxy part that is happening as we just discussed on each Hyper-V host. What about the iDNS server part?

iDNS Server

The iDNS server is the actual DNS server that will host the tenant’s zones. It can also resolve internet domain names when VM’s will try to reach public url’s. Let’s take a look at how this is implemented in Azure Stack.

I logged in the network controller and execute the Get-iDnsConfiguration cmdlet from the NCRestWrapper functions:

It provided me with a DNS zone that is being used for the iDNS server and the DNS server IP address that is being used to store the zone.

I opened DNS MMC and added the domain controller and indeed. Here I found my internal.azurestack.local zone. When I expanded the GUID folder it shows me my single VM in my network:

On the DC DNS:

Now my next question was: Where is this GUID come from? Might be desired to know how this is segregated in the DNS server. I opened PowerShell and retrieved my virtual network:

Get-AzureRmVirtualNetwork -Name Test-vnet -ResourceGroupName Test

You’ll see that the ResourceGuid of my virtual network is the GUID matching in the DNS server. So that answers also my question that when I use multiple subnets in a virtual network that all these resources will end up in the same zone. Which is in most cases is desired in my opinion. Because when the boundary was done on subnet that would mean my frontend VM’s won’t be able to reach my backend VM’s by hostname name or I needed a custom DNS implementation.

Let’s take a look at an example when I have multiple VM’s deployed and I try to ping another VM in my network. I have created 20 VM’s and you will see that they are all in my own DNS Zone.:

When I log in to VM0 and try to ping VM1 you will see: 1) yes, FW is turned on. But 2) the VM is able to resolve the FQDN for this VM:

It is taking the DNS Zone (internal.azurestack.local) and adds in front of it the ResourceGuid for the virtual network(d847d21d0b741-4de0-9ec6-0ad4ff106611)

So I hope that its clearer on how iDNS is working under the hood in Azure Stack. If you have any questions or comments leave them below!