Closed xdansmith closed 3 years ago
@xdansmith Thanks for your feedback! We will investigate and update as appropriate.
@xdansmith Azure Front Door requires a CNAME record, so you would need to make a new CNAME record based on your @ (A) record.
@xdansmith We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.
@TravisCragg-MSFT can you elaboate on your recommendation to
Azure Front Door requires a CNAME record, so you would need to make a new CNAME record based on your @ (A) record.
as Apex records do not support CNAME records
@ADNewsom09 you should be able to create a CNAME to point to your @ record.
@TravisCragg-MSFT
@ADNewsom09 you should be able to create a CNAME to point to your @ record.
My registrar does not allow it (google domains), also speaking with several other registrars they will not allow it either. see https://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain as an example
Also i found this which looks like a request to add this functionally.
Anyone find a solution for this yet? Even ALIAS entries (e.g. like those from DNSimple) are not accepted. I'm not finding a way to make front door work with Apex domains. It would be nice if the DNS check could be skipped (both the portal and the cli enforce the DNS CNAME validation)
@TravisCragg-MSFT CNAMEs on the domain apex / @ record are not allowed by DNS.
This is because if there is a CNAME record for a name, there can not be any other records (other than DNSSEC records) on the name.
Since the domain apex must have SOA and NS records, it can never have a CNAME.
This special niggle of DNS can be found explained by a multitude of sources on the internet with a quick search, for example here: https://medium.freecodecamp.org/why-cant-a-domain-s-root-be-a-cname-8cbab38e5f5c (In fact, my explanation above is a quick and dirty paraphrase of the relevant paragraphs in that article).
Most DNS-based ownership verification methods use TXT records instead which are much less problematic.
(Technical pedantry note: There are DNS servers that do not enforce the CNAME exclusivity rule. For better or worse, these servers just allow users to build DNS zones that do not conform to the DNS standards. This doesn't change the fact that it is not allowed by DNS and is not good practice.)
@ckittel @duk3luk3 I am reopening this issue.
@sharad4u can you please elaborate on what the best practice would be for mapping apex domains using Azure Front Door?
@TravisCragg-MSFT thank you very much for reopening the issue.
On thinking about this some more and rereading the documentation, it is quite possible that Front Door will not be able to support hosting websites for Apex records, at least not in a blessed and supported way because Front Door will not offer fixed public IP addresses for its frontend servers.
There is some previous discussion here: https://feedback.azure.com/forums/217313-networking/suggestions/35530549-add-custom-apex-naked-domains-as-front-end-hosts
if this can be confirmed it would be good to add the information that apex domains cannot be used to the documentation.
How can Traffic Manager support alias records and this not?
It seems that you can now point an apex record at an Alias record set and use the Alias type of Front Door. However, when I try and select the Front Door resource that appears in the list, a Resource Not Found error is thrown. Which is odd as it was able to show the Front Door resource in the drop down list??
Currently, we deploy global solutions using Azure Traffic manager->AppGateway->Web App. For customers hosting their DNS in Azure DNS we can use alias record and point apex domain to Azure Traffic Manager CName. This does require us to convert all of our traffic manager nested endpoints to be type external. We want to start using Azure Front Door. Its WAF is GA now so we were hoping to get rid of Application Gateways. Before we can do down this we do want to have a solution for alias/apex/AFD issue referenced above.
This is a bug. And the current workaround/solution is that your AFD resource name and the is Resource Group name must be lowercase.
This appears to be working now, or at least it did just now for me.
As @deploymentking noted above, the Front Door service shows up in Azure DNS when creating an alias record. It worked for me though, no errors.
Now the one bit that still doesn't work is the automatic SSL certificate - have to use my own.
This worked for me with a .com domain but fails with a .cc domain :( - Logging a support ticket
If the Public DNS server that is in use does not support the Alias record then this can be achieve very simple:
Use CNAME with afdverify option to pass the validation step: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain#map-the-temporary-afdverify-subdomain
Add the Public IP to the backend pool with the correct backend host header in this case "contoso.com"
Then once ready to steer the traffic via the FD just modify the A record on your public DNS server to point to the FD IP: 13.107.246.10, is very unlikely that this IP change.
Closing this for now since there is a documentation for onboarding APEX domain now.
How do you recommend mapping the root of a domain (like contoso.com, instead of www.contoso.com), since DNS doesn't support CNAME's for the @ record?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.