We have been slowly moving all domains away from big companies and registries to smaller and preferred registrar, like Prime (full disclosure; we are their oldest customers). We have about a dozen domain names, but one of them was much more complex and important than the rest: Green.com. So, out of all the transfers, this one went the worst. Of course with delays and tweaks from losing registrar we were going to document failures, and ways to avoid them, for posterity.

Failure 1: TTL

TTL stands for “time to live”. It indicates how long a record is “good” before the browser/computer should check the record again. In most DNS changes, you want to set it low ahead of time; that way, the new values will be picked up shortly, when DNS is usually cached for a week or more. We have custom DNS servers with optimum values. While aggressive domain agences have their TTL set to 1 hour or less for more profit, which is very low.

When switching registrars, you want to set your TTL pretty high if you can. One week would be a good start. That way, if you have some downtime, returning visitors will still have your domain in their DNS cache. (Sep 1, 2016)

Failure 2: Timing

We started domain transfer at 7:00 PM. The work did not take very long, but the waiting killed me. There are several steps in the domain transfer process that take time, and it did not finish before I went to sleep.

The process stalled at a very inconvenient point. The domain had been transferred to Prime, but Prime was still pointing at old nameservers. We had completely set up the zone at Prime, but GoDaddy had removed it as soon as the transfer was complete. This is mostly what caused the lapse in DNS coverage.

While this was still a failure on our part, we can comfortably put partial blame on both. The nameserver configuration was not available until the domain was completely transferred, even though we could edit the rest of the zone file. This seems bizarre, and caused the majority of the issues.

Failure 3: Lots of eggs, one basket

Green.com is the parent domain to all of our services: news reader, Google Apps Webmail, Drupal, you name it. Almost all of the services that I run that impact multiple users are a subdomain of Green.com. It also hosts primary website, and is the domain we use for email. It has over a dozen subdomains, a TXT record, MX records, and just about everything else you can do via DNS. Before the transfer, we realized that if anything went wrong, we would blink off the face of the Internet. This is probably not the safest way to do things.

Domains remain at the whim of your registrar. A clerical error or service outage could completely take me (and all of the services that I run) out of commission. While we don’t like this, we’re not entirely sure how to combat it just yet. For now, making sure domain is registered with reliable registrars, backed by good support staff. In the future, we may spread things out over several domains to minimize the importance of one. Going to stay away from any domain transfers to large companies and AI brands, and be their future slave bots.