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 custom domain name considerations in Multitenant applications.  

The previous article talked about the subdomains and custom domains for multitenants such that the requests can be routed to the respective tenant. This article talks about all other aspects of routing.

Mapping the request to a tenant is a necessity when the multitenant solution is hosted on different geographical regions. The physical infrastructure that hosts the tenant’s resources must receive the request.

Domain names identify the tenants.  The request to a tenant can be mapped to a tenant using the Host header or another HTTP header that includes the original hostname for each request but the following considerations need to be made.Will the users know which domain name to access the solution with? Is the landing page or login page common to all tenants? What is required to verify access to a tenant? Is it just authorization tokens or is it tenant-specific domain names as well.

The HTTP request properties include the url path structure, a query string and custom headers. The tenant information can be specified in all of these.

The resolution of tenant varies between subdomains and custom domain names. In a multitenant application, tenants might want to bring their own domain names. This might be important for branding for business purposes. It might also be technical that they might need to supply their own TLS certificates which bear subject names. These custom domain names for tenants require additional considerations than subdomain names. 

Name resolution is one of the considerations. The name resolution to an IP address depends on whether there is a single instance or many instances of the multitenant application. For example, a CNAME for the custom domain of a tenant might have a value pointing to a multi-part subdomain of the multitenant application solution provider. Since this provider might want to set up proper routing to multiple instances, they might have a CNAME record for subdomains of their individual instance to route to that instance. They will also have an A name record for that specific instance to point to the ip address of the provider’s domain name. This chain of records resolves the requests for the custom domain to the ip address of the instance within the multiple instances deployed by the provider. 

Host header resolution is also significant. All the web components need to be aware of how to handle the requests that arrive with the provider’s domain name in their host request header. Each tenant’s domain name might be a subdomain or a custom domain and this adds operational overhead to the onboarding of tenants. Host headers can also be rewritten by say the Azure FrontDoor so that the web server receives a single Host header. The example of Azure FrontDoor also propagates the original value of the host header in a X-Forwarded-Host header so the multitenant application can properly resolve the tenant. 

Validation of custom domains is a necessity for the tenants to be onboarded. Without validation, tenants might accidentally or maliciously park a domain name. Typos in custom domain names are encountered often. Parking leads to an error for others wanting to use their custom domain with the message that the domain name is already in use. Domain names especially withing a self-service or automated process require a domain verification step. A CNAME record or a DNS TXT record might be added to reserve the domain name until the verification is completed. 

Dangling DNS and subdomain takeover attacks are more likely to hit custom domains. This attack happens only when customers disassociate their custom domain name from the service but they don’t delete the record from their DNS server. In this case, the DNS entry points to a non-existent resource and is vulnerable to a takeover.  This can be avoided if the CNAME record for the tenant is deleted from the DNS server before the domain name can be removed from the tenant’s account.