CNAMES vs. A-Records for Custom Domain Names
I remember asking Marco and the Tumblr support alias this question several times back when I started using Tumblr, but never got a reply, so I’ll pose the question here:
“Why does Tumblr use A-records for custom domains rather than CNAMEs?”
For those of you who don’t know the nuance of the question, a CNAME is essentially an alias from one host name to another, whereas an A record is a mapping of a hostname to an IP address.
mail.daryn.net. IN CNAME ghs.google.com.
means that a lookup of mail.daryn.net will result in a lookup of ghs.google.com, which could also either be a CNAME, or and A record that resolves to an IP address.
blog.daryn.net. IN A 72.32.231.8
means that blog.daryn.net points to the IP address 72.32.231.8, which happens to be the IP of the web server at rackspace that serves this tumblelog.
The issue arises when tumblr wants/needs to move its servers at some point, and because porting IP ranges can be a major pain in the ass, they will just want to change their DNS to the IP addresses provided at the new hosting facility. Unfortunately, since everyone with a custom domain has an A record pointing at the old address, we’ll all have to go to our dns/registrar/hosting providers and change this as well. It’s not hard, but it is a much bigger coordination effort, and can’t happen transparently on the tumblr end.
This is a little over-simplified, and there are potentially ways to take care of this with additional routing, and/or proxying at the application layer, but those seem like unnecessary overhead. CNAMEs do have some limitations (you’d have to use a unique hostname since a CNAME has to be the only RR for a given name) and there is theoretical performance overhead versus an A record, but that isn’t true in practice because of the distributed and cached nature of DNS.
The general rule of thumb is to use A records if you control the SOA for all of the domains used, but otherwise use CNAMES to reduce the administrative overhead. This is, for example, how Google does it for Google Apps.
The Tumblr staff has put so much attention to detail in the application, that I figure their must be a reason for this choice, but I can’t think of it… I can it see being an oversight early on, but with the userbase growing rapidly, it seems like a problem that should be nipped in the bud. This isn’t meant to be overly critical of what tumblr has done, just concern, as it is one of those details that could cause a lot of strife at some point in the future.
