Azure DNS
Domains and Custom Domains
Initial domain name
By default, when you create an Azure subscription an Azure AD domain is created for you.
This instance of the domain has initial domain name in the form domainname.onmicrosoft.com. The
initial domain name, while fully functional, is intended primarily to be used as a bootstrapping
mechanism until a custom domain name is verified.
Custom domain name
Although the initial domain name for a directory can't be changed or deleted, you can add
any routable custom domain name you control. This simplifies the user sign-on experience by
allowing user to logon with credentials they are familiar with. For example, a
contosogold.onmicrosoft.com, could be assigned a simpler custom domain name of
contosogold.com.
Practical information about domain names
● Only a global administrator can perform domain management tasks in Azure AD, by default this is
the user who created the subscription.
● Domain names in Azure AD are globally unique. If one Azure AD directory has verified a domain
name, then no other Azure AD directory can verify or use that same domain name.
● Before a custom domain name can be used by Azure AD, the custom domain name must be added
to your directory and verified. This is covered in the next topic.
Verifying Custom Domain Names
When an administrator adds a custom domain name to an Azure AD, it is initially in an
unverified state. Azure AD will not allow any directory resources to use an unverified domain name.
This ensures that only one directory can use a domain name, and the organization using the domain
name owns that domain name.
So, after adding the custom domain name, you must demonstrate ownership of the domain name.
This is called verification. and is done by adding a DNS record (MX or TXT) that is provided by Azure
into your company’s DNS zone. Once this record is added, Azure will query the DNS domain for the
presence of the record. This could take several minutes or several hours. If Azure verifies the
presence of the DNS record, it will then add the domain name to the subscription.
✔️ Notice you can use a TXT or MX record.
Azure DNS Zones
Azure DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual
network without your needing to add a custom DNS solution.
A DNS zone hosts the DNS records for a domain. So, to start hosting your domain in Azure DNS, you
need to create a DNS zone for that domain name. Each DNS record for your domain is then created
inside this DNS zone.
From the portal you can easily add a DNS zone and then view information including name, number
of records, resource group, location (always global), subscription, and name servers.
Considerations
● The name of the zone must be unique within the resource group, and the zone must not exist
already.
● The same zone name can be reused in a different resource group or a different Azure subscription.
● Where multiple zones share the same name, each instance is assigned different name server
addresses.
● Only one set of addresses can be configured with the domain name registrar.
✔️ You do not have to own a domain name to create a DNS zone with that domain name in Azure
DNS.
However, you do need to own the domain to configure the domain.
DNS Delegation
To delegate your domain to Azure DNS, you first need to know the name server names for your
zone. Each time a DNS zone is created Azure DNS allocates name servers from a pool. Once the
Name Servers are assigned, Azure DNS automatically creates authoritative NS records in your zone.
The easiest way to locate the name servers assigned to your zone is through the Azure portal. In this
example, the zone ‘contoso.net’ has been assigned four name servers: ‘ns1-01.azure-dns.com’, ‘ns2-
01.azure-dns.net’, ‘ns3-01.azure-dns.org’, and ‘ns4-01.azure-dns.info’:
Once the DNS zone is created, and you have the name servers, you need to update the parent
domain. Each registrar has their own DNS management tools to change the name server records for
a domain. In the registrar’s DNS management page, edit the NS records and replace the NS records
with the ones Azure DNS created.
✔️ When delegating a domain to Azure DNS, you must use the name server names provided by
Azure DNS. You should always use all four name server names, regardless of the name of your
domain.
Child Domains
If you want to set up a separate child zone, you can delegate a sub-domain in Azure DNS. For
example, after configuring contoso.com in Azure DNS, you could configure a separate child zone for
partners.contoso.com.
Setting up a sub-domain follows the same process as typical delegation. The only difference is that
NS records must be created in the parent zone contoso.com in Azure DNS, rather than in the domain
registrar.
✔️ The parent and child zones can be in the same or different resource group. Notice that the
record set name in the parent zone matches the child zone name, in this case partners.
DNS Record Sets
It's important to understand the difference between DNS record sets and individual DNS
records. A record set is a collection of records in a zone that have the same name and are the same
type.
You can add up to 20 records to any record set. A record set cannot contain two identical records.
Empty record sets (with zero records) can be created, but do not appear on the Azure DNS name
servers. Record sets of type CNAME can contain one record at most.
The Add record set page will change depending on the type of record you select. For an A record,
you will need the TTL (Time to Live) and IP address. The time to live, or TTL, specifies how long each
record is cached by clients before being requeried.
DNS for Private Domains
By using private DNS zones, you can use your own custom domain names rather than the
Azure-provided names available today. Using custom domain names helps you to tailor your virtual
network architecture to best suit your organization's needs. It provides name resolution for virtual
machines (VMs) within a virtual network and between virtual networks. Additionally, you can
configure zones names with a split-horizon view, which allows a private and a public DNS zone to
share the name.
If you specify a registration virtual network, the DNS records for the VMs from that virtual network
that are registered to the private zone are not viewable or retrievable from the Azure Powershell
and Azure CLI APIs, but the VM records are indeed registered and will resolve successfully.
Azure DNS benefits
● Removes the need for custom DNS solutions - Previously, many customers created custom DNS
solutions to manage DNS zones in their virtual network. You can now perform DNS zone
management by using the native Azure infrastructure, which removes the burden of creating and
managing custom DNS solutions.
● Use all common DNS records types - Azure DNS supports A, AAAA, CNAME, MX, PTR, SOA, SRV,
and TXT records.
● Automatic hostname record management - Along with hosting your custom DNS records, Azure
automatically maintains hostname records for the VMs in the specified virtual networks. In this
scenario, you can optimize the domain names you use without needing to create custom DNS
solutions or modify applications.
● Hostname resolution between virtual networks - Unlike Azure-provided host names, private DNS
zones can be shared between virtual networks. This capability simplifies cross-network and service-
discovery scenarios, such as virtual network peering.
● Familiar tools and user experience - To reduce the learning curve, this new offering uses well
established Azure DNS tools (PowerShell, Azure Resource Manager templates, and the REST API).
● Split-horizon DNS support - With Azure DNS, you can create zones with the same name that
resolve to different answers from within a virtual network and from the public internet. A typical
scenario for split-horizon DNS is to provide a dedicated version of a service for use inside your virtual
network.
● Available in all Azure regions - The Azure DNS private zones feature is available in all Azure
regions in the Azure public cloud.
Private Zone scenarios
Scenario 1: Name resolution scoped to a single virtual network
In this scenario, you have a virtual network in Azure that has a number of Azure resources in
it, including virtual machines (VMs). You want to resolve the resources from within the virtual
network via a specific domain name (DNS zone), and you need the name resolution to be private and
not accessible from the internet. Furthermore, for the VMs within the VNET, you need Azure to
automatically register them into the DNS zone.
In this scenario, VNET1 contains two VMs (VM1 and VM2). Each of these VMs have Private
IPs. So, if you create a Private Zone named contoso.com and link this virtual network as a
Registration virtual network, Azure DNS will automatically create two A records in the zone. Now,
DNS queries from VM1 to resolve VM2.contoso.com will receive a DNS response that contains the
Private IP of VM2. Furthermore, a Reverse DNS query (PTR) for the Private IP of VM1 (10.0.0.1)
issued from VM2 will receive a DNS response that contains the FQDN of VM1, as expected.
Scenario 2: Name resolution for multiple networks
Name resolution across multiple virtual networks is probably the most common usage for
DNS private zones. The following diagram shows a simple version of this scenario where there are
only two virtual networks - VNet1 and VNet2.
● VNet1 is designated as a Registration virtual network and VNET2 is designated as a Resolution
virtual network.
● The intent is for both virtual networks to share a common zone contoso.com.
● The Resolution and Registration virtual networks are linked to the zone.
● DNS records for the Registration VNet VMs are automatically created. You can manually add DNS
records for VMs in the Resolution virtual network.
With this setup, you will observe the following behavior for forward and reverse DNS queries:
1. DNS queries across the virtual networks are resolved - A DNS query from a VM in the Resolution
VNet, for a VM in the Registration VNet, will receive a DNS response containing the Private IP of VM.
2. Reverse DNS queries are scoped to the same virtual network - A Reverse DNS (PTR) query from a
VM in the Resolution virtual network, for a VM in the Registration VNet, will receive a DNS response
containing the FQDN of the VM. But, a reverse DNS query from a VM in the Resolution VNet, for a
VM in the same VNet, will receive NXDOMAIN.
