Application Gateway and Hostname passthrough

Problem statement: Azure public cloud recommends the use of a firewall such as with an application gateway that faces the internet traffic destined to the application services. The app services and the app gateway their own default fully qualified names. Callers sending traffic to the app would want to continue sending the same hostname because this is sent by the browser from various clients and understood by virtually all the elements of the network. When the app services retain their default names and the traffic must come through the application gateway, the hostname is overridden by the gateway for proper routing and the app services are reached by path. This situation is avoided by introducing a custom domain and having the hostname retained but prefixed to the custom domain. There are two steps involved, first each app service in the backend pool of the app gateway must be put in the same custom domain and then the topmost record must be made to point to the application gateway. The problem is that it is hard to add a custom domain to the app service because the validation fails. This article elaborates on the solution.

The process of adding a domain to an app service is made smoother with the use of application domains and application certificates that are managed by Azure. When we specify a custom domain, it can be something other than what Azure provides such as when the apps are part of an organization and there is a top domain. When a domain other than the App Domain is specified, then the portal suggests two DNS records to be added for the application in the DNS Zone corresponding to the domain. These are CNAME record and TXT record when the domain name specified is part of an existing domain such as that of the organization. If the domain name is new and has no parent-child relationship, then the suggested records are A record and TXT record. In these cases, the records other than TXT record point to the default name of the app service while the TXT record points to a hash value specific to the app service. This hash is used to get the app service to join the domain properly and the handshake between the DNS zone for the domain and the app service must validate the TXT record. It is this validation step that fails often for many people.

Other than the purpose of validation, those TXT records can be done away with and the suitable replacement of the top domain with the help of an A record for the application gateway suffices. All these records are identified by a reference to their hostname. These identifiers can include @ for blank values to denote the topmost resolution for the DNS zone for various types of records. They can also include reserved names such as ‘asuid’ for TXT records that have hash values from the app service so that the record can be located by suffixing asuid with the domain name. Even though this record might exist, the validation might fail stating that a record for such asuid.domain.com was not found.

Before falling back to the default naming convention that avoids the use of custom domains, there are some mitigations to try. For example, we could add a TXT record for ‘awverify’ reserved name that points to the default name of the app service. Another correction might involve making sure the ‘asuid’ is not suffixed with any other name parts when specifying the TXT record with the hash value of the app service.  Getting a DIG report generated by a DNS lookup tool from Google might also help with transparency to the resolution. Finally, DNS names can take anywhere from one hour to 48 hours to propagate.