What records can I create?
Type | How is it created? | What can I create? |
---|---|---|
Public | Manually | A / AAAA / CNAME |
Private | Manually & Auto-Registration | Full Range of Records i.e., TXT, MX, SVR, SOA etc. |
Public DNS
As the name would suggest – Public DNS zones allow you to create publically resolvable domain names. As Microsoft does not allow you to purchase domain names directly, you’ll still need a domain registrar to purchase and manage the domain name bit you could then point the name servers to the Azure name servers.
Private DNS Zone
Private DNS zones are far more interesting and customisable than public.
Default Azure DNS
The Azure DNS service, which is always an IP address of 168.63.129.16 is the default when creating a VNET in Azure. It’s worth nothing that this is not routable; in other words, you could no configure your on-premises VMs to use this as its DNS server.
Having said that – it is possible to use DNS forwarders on your on-premises to a DNS server within Azure that has Azure DNS configured. This would allow on-premises machines and services to resolve DNS from Azure DNS. Microsoft has a pre-defined ARM template to make setup simple - DNS Forwarder VM (microsoft.com)
Custom DNS
If you had a particular need to use a custom DNS service – Active Directory DNS or BIND etc. you can override and select ‘Custom DNS’ instead. It is possible to do this at both a VNET and a per-NIC level. If both are configured Azure would use the NIC DNS settings over the VNET DNS settings.
Internal DNS
When you create a VNET it is always created with an internal DNS zone (sometimes known as the iDNS zone for the VNET). This is automatic, you don’t have to deploy anything, Azure does this for you when you provision a new VNET. The zone is completely free however you are unable to manually create any records, Azure does this for you. Any Virtual Machine that is created within the VNET will be registered into the namespace is internal.cloudapp.net and will be resolvable from both the Azure Default and Custom DNS.
You can see this if you connect to a virtual machine and look at the DNS:
Registration You can only have a virtual machine registering to a single DNS zone – but you can have multiple VNETS registering to the same zone.
Resolution You can look up against up to 1000 private DNS zones.
Example: In this example I have created a single private DNS zone – buildingyourcloud.co.uk:
You can see the single SOA record in the zone. However, this doesn’t do anything – by default this is just an island by itself, nothing is going to use it. I need to link this DNS zone to my VNET:
When setting up the link I can say if I want to auto-register with the zone. With this option enabled Azure will take of any newly created virtual machines, changes to a VMs IP address, or when the VM gets deleted.
Although I’m using Virtual Machine in this example here it’s worth noting that the same is true for all Azure resources that use VMs such as AKS, SQL Managed Instances etc. You cannot select which resources use the auto registration – if it’s enabled on the DNS zone ALL VM resources will use the auto registration.
Now if we go back to the Overview blade for the zone, we can see my demo VM has auto registered itself into this zone:
To test things out if I go back to my demo VM and do an IPCONFIG you can see that I still have the DNS suffix of internal.cloudapp.net however I can ping my virtual machine using my new DNS name:
If I tried to link another Private DNS Zone with ‘auto registration’ enabled I would get an error – don’t forget you can only have a VNET auto regrestering to a single zone:
I can however link another DNS zone that does NOT have the autogenerate enabled as this zone would then just ne used for resolution.