Provide a 301 (Permanent) redirect service for apex (naked) domains
Discussed in the Azure DNS docs: https://azure.microsoft.com/en-us/documentation/articles/dns-getstarted-create-recordset/#comment-2294403853
Right now, you must use a static IP address if you want to point an apex (naked) domain (e.g., mycompany.com) to a Cloud Service (e.g., mycloudservice.cloudapp.net). Static IP's are stable as long as the Cloud Service isn't deprovisioned; however, for maximum security, simplicity, and maintainability (i.e., even if a cloud service is deprovisioned), it would be awesome if we could have 301 redirects for the apex domain to a the www CNAME endpoint and not need to be concerned with the IP address of the Cloud Service at all. The scenario goes like this:
(1) The root domain (mycompany.com) should 301 (permanent) redirect to the www CNAME (www.mycompany.com)
(2) The www CNAME (www.mycompany.com) should direct to the Cloud Service endpoint (mycloudservice.clouadapp.net)
SEO would like that the best, as the 301 redirect would properly point traffic sources to the ONE endpoint we care about here (the 'www' endpoint).
We are evaluating this feature ask. However, it is not on our immediate roadmap.
I would love to see this feature enable
Hello, actually having the redirect is a function that can make all the difference.
as many services have the webhop.
Garcia, Jesus commented
Imagine application migrations at the Click of a button! That would be amazing!
Martin Helmer commented
This is the kind of detail, which makes life massively easier for everyone. Little feature, massive impact.
Rune Højsgaard commented
I'd also appreciate this feature
This works fine with Azure Front Door + Custom Domain + Cert + Azure Managed DNS with an Alias record in the root. Just configured a fair few for a client who was getting upset at lack of root domain.
Another method would be to change your SSL to IP based on App Services which pins the app service to a static IP, you can then just add a A record at root and use .htaccess to redirect if you want to www. If you manage the cert renewals in a particular way the IP apparently doesn't change.
CNAME flattening works fine for Front Door, would be great if it also worked for Native Azure App Services or Traffic Manager pointing at different app services.. at present it won't allow it as it can't find an IP.
Dyn has been doing this for years. CNAME Flattening.
We will have to suggest to all our current users who use Azure for DNS that they find a new provider as this is a necessary feature for our product.
If root domains could have a CNAME record this would also solve the problem for us
Moving subscriptions in azure causing extended outages for services - a 301 here without relying on other azure services - needing to go down as part of subscription changes - would be helpful to a third party non-azure for some web facing services.
Andrew White commented
Can't be that hard!! People have been asking for 4 years.
Walter Novoa commented
This is necessary for Static Web Hosting over blob storage! It is just ridiculous that you cannot assign a root domain to a static web site using a domain bought in Azure!
Please add this feature!
Vincent Yim commented
@Azure networking team: Is your official response to now use the Azure Front Door service's URL redirect feature? https://docs.microsoft.com/en-us/azure/frontdoor/front-door-url-redirect
Sad we have been waiting for this feature so long and its being ignored. I guess customers are no longer the kings.
need this, currently have to do with an a function
AWS already has url forwarding supported utilizing DNS and S3. I guess we'll have to stick with utilizing AWS for our DNS.
Please add this feature, really basic requirement. Come on MS sort it.
Aaron Kelly commented
Please add this feature. Migrating to Azure DNS is our preferred choice, but with this limitation in place, it makes the decision more difficult when we can utilize other providers with this capability.
Ajit K commented
We can move our external DNS services to Azure if URL redirection is supported. Please add this feature.
Martin Meixger commented
for reference: 4 years later this is still needed and now with the new free "Managed Certificates" also for http[s] non-www to www: