But sometimes, the systems that I use are so horrendously awful, and the pain of using them so great, I feel compelled to comment, if only because some unfortunate soul might stumble across my experiences and benefit from the lessons learned.
There are tons of reasons not to use GoDaddy. My goal isn't to build a case for all of them, but rather to chronicle one very specific problem with their service. As someone who has worked on and off with DNS hosting services of varying complexity since 1993 (at a University, at a startup ISP, as a small business owner, at a big, established .com startup, and at a couple smaller startups) I am a fairly well educated DNS consumer.
The problem I needed to solve on this particular day was to move a domain that was hosted at godaddy to a site I'm hosting at AWS on an EC2 instance. (In English, I needed to move a web site from GoDaddy to Amazon). Normally, this would be a straight-forward operation. You change the DNS, you wait for the records to propagate across the various DNS servers on the Internet, and your domain is moved.
One thing some Web users have noticed is that you can often visit a site at example.com as well as www.example.com. And this is how our site was configured as well, so I needed a solution to ensure that traffic to our site directed to "www." at our site.
The first thing you encounter when you use GoDaddy's administration tools is just how god-awful their UX is. Actually, referring to it as UX is doing the profession of user experience a great disservice. There's no single, simple interface to find what it is you want. There's several ways to do any given thing, and worse, there's multiple user interfaces for doing what are very similar, if not the exact, same thing. And each one looks just different enough to be completely baffling.
You have menus, submenus, and various different user interfaces, all which seem to have been designed by committee, or worse, by just some developer who's given the distinct privilege of putting the S in front of UX.
But if the user experience isn't awful enough (seriously, Jakob Nielsen could teach a semester course on how bad GoDaddy is), there are two things that are worse.
First, the sheer amount of plain wrong and woefully incorrect information and help text. In the same UI where they allow you to view (and separately, edit) the "DNS Zone File", they offer a control to "Manage" host names, which they gleefully tell you (assuming you have defined such "host names" in the Zone File) you have 0 defined, even though you may have several. As someone who knows a few things about DNS, you are immediately left pondering, "uh, what kind of marketing speak malarkey have they come up with where a host name is distinct and separate from your DNS zone file, and how in the world can I have none defined, when I most certainly do?"
So you hover over the somewhat promising help teaser (?) and it tells you the following:
Hostnames define a nameserver as a name instead of an IP address. You can use hostnames as nameservers.
Those of you who know a few things about DNS will be scratching your heads thinking, "who writes this stuff?!" Those who don't know DNS, that's the equivalent of saying "Gasoline defines a gas tank as molecule instead of a hydrocarbon. You can use gasoline as a gas tank."
Um no, you can't. I don't know how such a sentence even manages to get written, but at GoDaddy, it's apparently possible. A hostname provides a human readable name (www.google.com) to a service instead of an IP address (18.104.22.168). It really is that simple.
Now, normally, I wouldn't be so inclined to nit pick about some help text, but when you're digging to find some obscure setting somewhere, you end up looking under every rock.
The reason I was looking under this particular rock? Because I needed to know where exactly GoDaddy hides a feature called "naked domain forwarding". This is the concept of directing "example.com" to "www.example.com". Due to arcane aspects of DNS which I won't delve deeply into, you can not define a CNAME (when you hear CNAME, think "alias" or "pointer") as your top level domain because that would in effect direct everything on your domain to that location, and undermine the whole point of having different services configured differently as you need them to be.
Now, conveniently, GoDaddy offers a feature to forward your naked domain to any hostname you wish. They've managed to call this service "Forwarding" as you might expect. But, as they wouldn't want to have a string of two victories in a row, that's where the good news ends. When you actually open the panel to make changes, even though the UI tells you "Update my nameservers and DNS settings to support this change",... it doesn't actually work!
That's right, if you can manage to find one of the domain management UIs tucked in some menu somewhere, you'll not see any A records set up for your domain to actually make it work! Because you know, at GoDaddy, doing what you say you'll do doesn't mean you'll actually do it!
So, the wiser folks amongst you might think "well I know, I'll just uncheck that helpful little box! By doing that, the UI will think 'well the user hasn't actually updated their DNS to point to the A record that they need to so we can forward their traffic, so we'll tell them how to manually edit their zone file!'". But that would be a mistake, because to think that GoDaddy might do anything logical was your second mistake, the first being to use GoDaddy in the first place.
When you don't select the option, on the upside, it actually doesn't do what it didn't say it'd do in the first place. So at least it's consistent. But if you expected something to pop up and say "You're almost done! Now, you need to add an A record for your domain set to the IP address 22.214.171.124!", then expect to be sorely disappointed-- at least more so than you were already.
Your only saving grace, at this point, would be to Google "GoDaddy naked domain forwarding" which, it would seem, Google seems to have found on their site and which helpfully, finally, informs you that the A record you need to create is 126.96.36.199.
But wait, if you think that's the end of the story, there's more. To test that the changes were working, I telnetted to port 80 at that IP address, asking for my host name (as you saw above, you can refer to a server with both its name and its IP, and I was testing to make sure that things were correct).
When I did, I was greeted with this awesomeness:
$ telnet 188.8.131.52 80 Trying 184.108.40.206... Connected to ip-50-63-202-1.ip.secureserver.net. Escape character is '^]'. GET / HTTP/1.1 Host: example.com Connection: close HTTP/1.1 301 Moved Permanently Cache-Control: max-age=900 Content-Type: text/html Location: http://www.example.com Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Wed, 14 Aug 2013 01:09:41 GMT Content-Length: 0 Age: 0 Connection: close Connection closed by foreign host.
What you'll notice here is that not only should they not be advertising the technology they are using (it's trivially easy now to go to cvedetails.com and find a few remote exploits to use against them) what's worse is that the version of ASP.NET they're using was released in April 2010. I expect to go over to my technologically illiterate neighbor's house and find him running some outdated version of software using a password like "password". But for an ISP that puts as much resources as they do in advertising, perhaps some of those resources ought to be spent in improving their service.