Over the past few years, I've benefited from my friend Richard's "friends and family" hosting service, which meant that my website was behind a commercial grade firewall, on commercial grade solaris servers, in a carrier class hosting facility.

But the time and effort that Richard would pour into offering the kinds of business-class services one would see from a much larger hosting platform, like installing and managing spam filtering, and securing the services, is simply not worth the time for what is ultimately a consumer-grade need that I have.

So I've moved my services off of Richard's hosting platform (tip of the hat to you, Richard, for running the service for so long) to other services.

It started by moving my web hosting to a server I'm sharing with Richard at GoDaddy.com. For someone who has never done this, it's pretty straightforward. First, you copy your web files from the original server to the new one. You set up the web hosting configuration in Apache. You can then even telnet to the IP address of the new server (port 80), type in "GET / HTTP 1.1[return] Host: www.khan.org[return][return]", and if you see your HTML you know the server is ready to accept traffic at www.khan.org at that IP address.

What remains is simply to change your DNS 'zone' to say "the updated IP address of www.khan.org is now the new server's IP address". You leave both servers on for a couple days, and avoid making any changes (because DNS changes take time to propagate across the Internet's caching DNS servers), and after a couple days, you can shut off the services at the old server.

There's an advanced technique to invalidate the caches of the DNS servers by reducing the TTL (or time to live interval) of your domain-- say you change your site every 4 hours, and you don't want to or can't maintain your site in both locations (old/new) at the same time. By dropping the TTL to, say 5 minutes, a week in advance of your change (a week is a common default TTL), you'll have effectively told all the DNS servers on the Internet that your domain should only be cached for 5 minutes. Once that's been done, you can then update the IP address of your website, and within 5 minutes, the change will have propagated Internet-wide and disruptions would have thus been minimized.

My site isn't particularly time sensitive (often I blog 2-3 times a week) so a default propagation wasn't problematic and I didn't use this technique, but I thought I'd share it. Of course, you want to reduce load on your DNS server, so you should reset your TTL back to a longer value to make most effective use of DNS caching.

Anyhow that was how my website moved. The next step was making DNS changes to move my mail service, but ever since I installed OS X 10.5, my VPN tracker software broke and I didn't see the value of updating it since the only VPN I needed to use it with was the one for the network I was moving off of.

But this created a chicken/egg situation in that I couldn't change my DNS settings on Richard's server. Incidentally, my domains needed renewal, so the hunt was on to find a domain registrar that offers DNS services since the one I was using (Melbourne IT, which I chose originally since it was my former employer, Verio's chosen registrar) doesn't offer web-based DNS services.

The obvious alternative was GoDaddy.com, since that's where my website had moved.

The way that you change domain registrars is to initiate a transfer at the new registrar, who sends the administrative contact a notice that a registrar change has been requested. This is to ensure that the administrator must be aware, and approve, of such a transfer.

The next step is to approve the transfer, and then the administrator gets a request from the original registrar saying "you must provide your auth code" which you get from your old registrar's website to do a double-confirmation of the change.

The problem is GoDaddy is an incompetent registrar. Any DNS administrator that knows anything about DNS administration knows that it is illegal (in the sense that it violates RFC 2181) for an MX record (or the record that specifies which host should handle incoming mail for a domain) to point to an alias, called a canonical name, or CNAME.

And, you guessed it, that's exactly what they do-- their MX record points to a CNAME, and therefore when I requested to move my domain from MelbourneIT to Godaddy from their website, they attempted to send me email (at Richard's server) which was configured properly and promptly rejected receiving traffic from a mail exchanger whose MX points to a CNAME.

When I called GoDaddy, they had the gall to tell me that my mail server was misconfigured and tried to tell me that this wasn't a violation of the RFCs, and that they sent billions of emails every day and they needed the CNAMES so they could loadbalance their systems properly to send that much email.

Now there are barely a billion Internet users on the planet, so this claim is extremely dubious. If I had to guess there are fewer than 100 million domains on the planet, so GoDaddy's claim that they send billions of emails a day would mean that they send 20 emails per domain name on the planet each day.

Obviously, this is ridiculous. Assume that GoDaddy has 10% of the domain market (a generous figure), which means they have no more than 10 million domains. Let's further assume that each of those 10 million domains need some kind of notification or email sent for some reason (renewal, expiry, etc.) on a basis of once a year.

Even if it's twice a year, that's between 27,000-54,000 emails a day. Even if they suffer a spike that is 10x higher than the average, that's an email infrastructure that needs to send 500,000 emails a day.

Now I happen to work for a company who has the capacity to send that kind of email volume in an hour, and we don't need to use MX records that point to CNAMES. So their explanation of "we need CNAMES to scale our email architecture" is either false, or if true, indicates that their IT team are simply incompetent.

Richard likes to say "Never attribute to malice what can be explained by incompetence", so rather than casting GoDaddy as liars, I'd rather believe that they are clueless when it comes to domain administration which is precisely the business they are supposed to be in.

When calling the office of the president didn't resolve this issue, I got my refund and instead moved my domains to register.com, who, one would think, have the same scale of problems that godaddy have, and gee, I was able to receive email from them just fine.

Bottom line? If you have a domain, don't register your domain with godaddy.com.

As for register.com, their domain administration panel UI could use some improvement, but it works. (On a technical list I'm on, I also got recommendations for dreamhost, easydns, and 1and1, but register.com was my preference as they had the most brand recognition of the registrars I was aware of)

Coming in the next installment: Updating MX records and setting up Google Apps. Stay tuned!