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
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.