We welcome user feedback and feature requests!

Use actual endpoint testing for custom domains rather than checking CNAME value

Our domain is “example-domain.com”. Let’s say I’m trying to set up an App Service called “booking-service”, which will be assigned the default URL of “booking-service.azurewebsites.net”. At the *end* of this whole process, I want to have an App Service in Azure responding to the hostname “booking-service.example-domain.com”, sitting behind our CDN (Cloudflare).

The failing path:
Step 1: I create the App Service in Azure. This generates the “booking-service.azurewebsites.net” URL.
Step 2: I create the CNAME “booking-service.example-domain.com” on Cloudflare’s control panel pointing to “booking-service.azurewebsites.net”, leaving the proxy/CDN/IP-hiding feature *enabled*. While in their control panel, we select the “CNAME” record type, however in reality what they are doing is creating an A record in their DNS servers pointing to their own IPs and then proxying the requests to Azure, effectively “faking” the CNAME functionality behind the scenes.
Step 3: I attempt to use the Custom Domain feature in Azure to add the domain “booking-service.example-domain.com” to the Booking Service App Service.
Step 4: When the validation attempts occur, they fail (and this is only my assumption) because they are looking up “booking-service.example-domain.com” and finding that it is an “A” record type, rather than a “CNAME” and so it’s trying to protect me and tell me that I haven’t set things up correctly.

The current (and undesired) path:
Step 1: I create the App Service in Azure. This generates the “booking-service.azurewebsites.net” URL.
Step 2: I create the CNAME “booking-service.example-domain.com” on Cloudflare’s control panel pointing to “booking-service.azurewebsites.net”, leaving the proxy/CDN/IP-hiding feature *disabled*. This results in a “true” CNAME record being published
Step 3: I attempt to use the Custom Domain feature in Azure to add the domain “booking-service.example-domain.com” to the Booking Service App Service.
Step 4: When the validation attempts occur, they succeed because they are looking up “booking-service.example-domain.com”, finding that it is an “CNAME” record type, and pointing to the correct location.
Step 5: Now that validation has succeeded (and since it never happens again), I can immediately turn on the proxy/CDN/IP-hiding feature without issue; we consider this a “bad” thing, because at least temporarily, we exposed the fact that our website is hosted in Azure, which gives an attacker a much more targeted attack surface, since they know they don’t have to target other cloud providers, and also is an unnecessary extra step (one that Terraform doesn’t like; it only cares about the end state and so there isn’t a way that we’ve found to first set the hostname with CDN off, <do stuff>, and then turn the CDN on). It's also an extra, unnecessary step, and we don't like those.

Our proposed path:
Step 1: I create the App Service in Azure. This generates the “booking-service.azurewebsites.net” URL.
Step 2: I create the CNAME “booking-service.example-domain.com” on Cloudflare’s control panel pointing to “booking-service.azurewebsites.net”, leaving the proxy/CDN/IP-hiding feature *enabled*.
Step 3: I attempt to use the Custom Domain feature in Azure to add the domain “booking-service.example-domain.com” to the Booking Service App Service.
My proposed changes:
Step 4: Instead of (or at least as a secondary mechanism) confirming that the CNAME record exists like it’s expecting and is pointing to “booking-service.azurewebsites.net”, behind the scenes, do the following:
Azure generates a UUID (e.g. fd1f87dc-61e6-11e9-8647-d663bd873d93) and a validation code (e.g. H6CjZkYwYmzUB4dJEABuY9vv9cge4PL1OiR76tSdVyyFhN2leRrJg92S4YrsiAzTNCrzTDQwUlGMqf70Lsb1nYCESJ4IAQO43kmgEiiaqoJ8dmLWjxihNRyoMT08ijwK1EMJKWSRTM1RxjOVzIzLPY0NRAoJNGSkwKXXgSDwCrxyTDetYyUEF6ekwBhyHGkk5cjRJnxN)
Azure App Services temporarily publishes a “magic” page that is accessible via both hostnames; for example: “http://booking-service.azurewebsites.net/fd1f87dc-61e6-11e9-8647-d663bd873d93” and “http://booking-service.example-domain.com/fd1f87dc-61e6-11e9-8647-d663bd873d93” which contains the validation code
For the validation step, it visits both URLs and confirms that they are both accessible and that they both contain the same validation code
If they both contain the same validation code, we can be sure that the user has correctly set up their DNS, regardless of what the actual record type (A / CNAME) looks like

I realize that this is a little more complicated, but really, Azure isn’t really trying to confirm that a DNS record is set (this is just a means to an end), the actual goal is to make sure that the user has configured their software correctly so that their users/customers can reach their website. Our proposed solution does that while taking into account the fact that CDNs by their nature might “skew” the DNS lookup while still providing the same result, that the Azure user’s website is accessible to their customers.

15 votes
Vote
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
You have left! (?) (thinking…)
Justin Smith shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

0 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...

Feedback and Knowledge Base