Domain name considerations in Multitenant applications:   

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the domain name considerations in Multitenant applications.   

Just like identity pertains to a tenant, a domain name can also be used to identify a tenant. Requests are routed to the appropriate tenant based on the based on the subdomains and the custom domain names. 

A subdomain falls within a domain that is commonly shared across tenants. If the multitenant application is hosted by Contoso, all of Contoso’s tenants will be assigned subdomain names. The shared domnain name need not just be contoso.com and can have regional qualification such as us.contoso.com Many Azure Services use this approach. When subdomains are created under the domain name, there cannot be name collisions with the names of other tenants. The full domain name must be unique.

Wildcard DNS entries can be used to simplify the management of subdomains. Instead of creating DNS entries for individual tenants, a wildcard entry for *.contoso.com is sufficient to route all requests to a single IP address as with the use of an A record or to a canonical name as with the use of  CName record.

Subdomains with multi part stem domains allows many multitenant solutions are to be spread across multiple physical deployments. Multipart subdomain names help organize the tenants even across disparate geographical regions. When Contoso publishes a multitenant application for its customers, the tenant subdomains can map to the same CName so that adventureworks.contoso.com and fabrikam.contoso.com can be reached with the same CName record of us.contoso.com

Customers do not always need to publish a full name with the Contoso part from the company that hosts the multitenant applications. These can use custom domain names.

Azure DNS allows hosting a DNS zone and managing the DNS records for a domain in Azure. The domain must be delegated to the Azure DNS from the parent domain so that the DNS queries for that domain can reach Azure DNS. Since Azure DNS isn't the domain registrar, delegation must be configured properly.  A domain registrar is a company who can provide internet domain names. An internet domain is purchased for legal ownership. This domain registrar must delegate to the Azure DNS.  

The domain name system is a hierarchy of domains which starts from the root domain that starts with a ‘.’ followed by the top-level domains including ‘com’, ‘net’, ‘org’, etc. The second level domains are ‘org.uk’, ‘co.jp’ and so on. The domains in the DNS hierarchy are hosted using separate DNS zones. A DNS zone is used to host the DNS records for a particular domain. 

There are two types of DNS Servers: 1) An authoritative DNS Server that hosts DNS zones and it answers the DNS queries for records in those zones only and 2) a recursive DNS server that doesn’t host DNS zones but queries the authoritative servers for answer. Azure DNS is an authoritative DNS service. 

DNS clients in PCs or mobile devices call a recursive DNS server for the DNS queries their application needs. When a recursive DNS server receives a query for a DNS record, it finds the nameserver for the named domain by starting at the root nameserver and then walks down the hierarchy by following CNAMEs. The DNS maintains a special type of name record called an NS record which lets the parent zone point to the nameservers for a child zone. Setting up the NS records for the child zone in a parent zone is called delegating the domain. Each delegation has two copies of the NS records: one in the parent zone pointing to the child, and another in the child zone itself. These records are called authoritative NS records and they sit at the apex of the child zone