Intermediate CNAME for custom domain on FrontDoor
Custom domains on Front Door and App service do not work the same way.
Custom domains on Front Door and App service do not check DNS records for custom domains in the same way.
My usecase:
- I have hundreds of clients with custom domains they have registered on their own (like myclient.com)
- My clients use www.myclient.com to access our services
- My company owns mycompany.com
- I've asked them to add a CNAME like this: www IN CNAME client.mycompany.com
- I've setup this record: client.mycompany.com IN CNAME mycompany.azurewebsites.net
- We are using custom domains on App service with container and it works with "client.mycompany.com" as intermediary CNAME
I now want to use to Front Door.
So I was planning to:
- update my CNAME record for mycompany.com: client IN CNAME mycompany.azurefd.net
- add www.myclient.com as a custom hostname on Front Door
But it does not work: I cannot add www.myclient.com as Front Door checks for direct CNAME record while App service accepts indirect CNAME.
Right now, I have two solutions:
- do not use Front Door
- ask hundreds of clients to update a DNS record
Both of them are not acceptable.
Sylvain
shared this idea
Valid feedback. Open for customer upvotes
10 comments
-
Brian Vallelunga
commented
I'm working on a new product and would like to use FD as well. We do not want our customers directly adding CNAMES to our FD instance, but that is the only option. If we ever need to migrate to another service or FD instance, each customer would have to update the records.
Please allow FD to validate by following a CNAME record so we can do: app.mycustomerdomain.com -> cloud.myapp.com -> myapp.azurefd.net
-
Moroney, Ian
commented
Indirect cname is the only way for us right now to use front door for one of our clients because azurefd.net does not support DNSSEC.
We attempted to cname to our domain which does support it, to azure front door and the traffic wasn't routed due to this issue.If DNSSEC isn't going to be supported by azurefd.net, we at least need the ability to use indirect cnames.
-
Sergey Kostrukov
commented
1.5 years has passed since it's "valid feedback", any progress so far?
-
David Catteuw
commented
For us this is very important functionality as well...
-
Magnus
commented
Seems like this is not that important for Microsoft although lots of people are in need of it. In my opinion when I heared of the frontdoor service it was obvious to me that this functionality must exist. Otherwise I cannot imagine for what this service should be good for
-
Pascal Enz (Group)
commented
I'm facing a similar issue. We would like to manage Front Door configuration with Infrastructure as Code and deploy changes to a staging instance and run tests (using custom host header) before deploying to production. But the CNAME check prevents us from doing that. Please add an option to disable the CNAME checks.
-
Anthony Super
commented
This is a massive issue for us too. We were hoping to onboard over 200 existing custom domains onto this service, but cannot due to the CNAME limitation as described above.
It would be even better if the CNAME validation could be disabled completely - we know what we are doing!
Thanks.
-
Brian
commented
I face the same problem. I cannot use this service until resolved!
Please either support an intermediate cname or add support for an http-01 style challenge. (https://letsencrypt.org/docs/challenge-types/)
-
Clément Fleury
commented
@azurecxpuservoice : What's the status on this ?
-
Nico VanHaaster
commented
We are currently in need of this solution. We would rather our clients add a CName to our public CNAME record instead of directly to the Front Door DNS Record.