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.     

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.