Allow adding custom hostnames before DNS CNAME is set up on Azure Front Door
Allow adding custom hostnames before DNS CNAME is set up. That way we could prepare the Front Door configuration before setting it live on our domain. This is useful for scenarios when some transitions to Front Door (for example from Traffic Manager) with a domain which is already in use in production.
valid suggestion subject to upvote
This is implemented now, right?
At least we were able to do what Michel mentioned using the afdverify.my.domain pointing to afdverify.myafd.azurefd.net
Agreed! Running into this issue trying to automate the deployment of FrontDoor through Azure DevOps.. I'm not sure how this is "Triaged"
This is sorely needed. Right now when migrating from traffic manager to Front Door, the domain verification part does work using the adverify CNAME approach (https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain#map-the-temporary-afdverify-sub-domain) BUT this does NOT work for SSL certificates issued by FrontDoor.
Frontdoor/DigiCert attempts to email domain admins at (subdomain).example.com - which for most customers won't exist since most customers have a mail server only on their primary domain; certainly not at admin@(customer-tenant001).example.com.
Secondly, DigiCert (which verifies and issues the actual SSL certificates) is incompatible with the CNAME adverify approach so they end up never issuing the certificate even after several days.
The bottomline is that migrating from Traffic Manager or other cloud providers is a non-starter if we cannot 100% prepare Frontdoor to start accepting production traffic.
Oskam, J (Jurjen) commented
When this is implemented, please make sure that it is possible to deploy Front Door with a custom domain *including HTTPS certificate* and the required CNAME as an Azure DNS alias record from the same ARM template.
Currently, to deploy an Azure DNS alias record the target resource must already exist, and to deploy Front Door-with-custom-domain the DNS record must already exist. Oops.
Suggestion: make it such that when the customHttpsConfiguration property is not specified, any existing HTTPS configuration remains unchanged. Only when customHttpsConfiguration is explicitly set to an empty object should it be removed.
This would make it possible to deploy Front Door with customHttpsConfiguration unset first, then deploy the Azure DNS alias record with the new Front Door as target, and finally deploy the Front Door again with the proper customHttpsConfiguration.
(It would be even better when Front Door would make use of nested resources like CDN does, so you can deploy a resource of type "Microsoft.Network/frontdoors/profiles" first (which would create the <name>.azurefd.net DNS entry), then the alias DNS record with a dependency on the profile, and then deploy a resource of type "Microsoft.Network/frontdoors/profiles/customDomains" which includes the custom domain and any specified HTTPS configuration)
Michel Zehnder commented
You can already do this by using the afdverify option to verify custom hostnames.