My first reaction was that this is a crock... after all, don't all the big hot internet companies use root domains? But I looked into it, and Facebook, Google, Apple (and Heroku) .coms all redirect to www. Only Twitter rocks the bare root domain.
I rely heavily on root domains in my printed materials (sending people to sproutrobot.com/water and such), but I'm starting to think redirecting users to www--so bookmarks, social media and the like point there and the majority of my users hit www first--is a good idea.
If you were worried about non-www links working during downtime/issues, you could setup multiple cheap hosts around the world with nothing more than a rewrite to the www. subdomain (where your main app is hosted). Then add the multiple IPs to your root domain's A records - that way you have no configuration to worry about (the non-www hosts literally just redirect to the same path on a different domain), and you don't have to worry about those redirects going down due to DNS round robin on multiple hosts.
This is an interesting point. The www. prefix seems to be slowly fading away from the landscape, but URLs without the prefix never felt like first-class citizens on the web.
The inability to use CNAMEs in root level domains also affects other aspects, such as load balancing [1].
My reading of the heroku post seemed to indicate that the recommendation is for heroku customers only. Of course, if your own systems are using reverse proxy to serve up content, then the advice may also apply to you.
I think "www" will make a comeback with increasing popularity of non .com/.net/.org TLDs. "whatever.io" looks like a web address to most of us here, but not to many others, even computer-savvy "normals".
A records are name-to-IP, CNAME are name-to-name. When you control everything, you're right, no big deal. But in this case, customers control the DNS and Heroku the servers. Using CNAME to point to an A record at Heroku allows them to decide what IP the traffic goes to. If you use an A record, Heroku is SOL if they need the traffic to go to a new IP.
Posterous has a similar problem last august. They urgently needed to change to a new IP, but all their clients were setup with A-records. Painful.
Ok. So I'm correct in thinking that for my own domains that I manage it boils down to the same thing, e.g. there is no reason to prefer www CNAMEs over domain A records.
Might this be an argument for a new DNS record which acts like CNAME but doesn't have the restriction there be no other records for the same host? Something that functions like an A record but tells the querying software that it should use the IP address from the A record of the returned hostname. An "ALOOKUP" record if you will.
It has frustrated me for years that DNS recognized that mail might like to have multiple hosts that can respond to a domain, but failed to recognize that there might someday be other protocols that would like the same.
This is pretty much par for the course with 90% of the 'cloud' offerings out there. This is also true with various hosted application platforms where you can add a custom domain for your blog or whatever.
There's just no way to ever rely on a single IP and guarantee that it will be stable for consumers, without failover. Even your ISP gives you two nameservers for that reason.
Amazon's Elastic Load Balancer supports only CNAMEs, so a redirect to www subdomain is the only option for us to use the load balancer, and I think the situation won't get any better...
The limitation of the root can (and will, I predict) be overcome by combining host and dns provider APIs. If Heroku had a way to push A record changes up to applications using their infrastructure they would be able to deal with this sort of issue.
This is also the promise of Amazon's Route 53 combined with their Elastic Load Balancing service which I hope will be released soon. Your DNS could dynamically serve A record IPs for the ELB, and you save the client the 2nd DNS resolution for the CNAME, faster and more dynamic.
They should update their dev center docs with this! I just followed their own instructions to set up DNS, which are to put in the IP addresses rather than the proxy. Kinda funny this came up right after I did it.
That would be a violation of the DNS specification, and won't work with DNS servers that are compliant to the specification (i.e. BIND). Section 2.4 of 1912:
2.4 CNAME records
A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu, or an A record, or
even a TXT record. Especially do not try to combine CNAMEs and NS
records like this!:
podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4
This is often attempted by inexperienced administrators as an obvious
way to allow your domain name to also be a host. However, DNS
servers like BIND will see the CNAME and refuse to add any other
resources for that name. Since no other records are allowed to
coexist with a CNAME, the NS entries are ignored. Therefore all the
hosts in the podunk.xx domain are ignored as well!
i want to bring up another - unrelated - point for "why a www subdomain is a good idea". the answer is: stupid CMS. forums, comment sections, press release distribution services, ... sometimes have issues to correctly transform non-www domain names into clickable links.
I rely heavily on root domains in my printed materials (sending people to sproutrobot.com/water and such), but I'm starting to think redirecting users to www--so bookmarks, social media and the like point there and the majority of my users hit www first--is a good idea.