Changing hosts

One of the big advantages of the domain name system is that your domain can move IP addresses, and thus can move to any provider in the world. But this is not an entirely simple process. To understand why, you need to understand the system of "timeouts".

Fair warning: this section is long and fairly technical. Depending on your inclinations you may want to skip it now. You don't need it for purchasing and setting up a domain name, however, you'll need most of it the first time you change hosts, especially if you want to do it quickly. Feel free to skip this now and return to it when you're switching hosts, or to skim it now and return to it when you're switching hosts.

Caching DNS queries

As you can probably imagine, DNS has the potential to create a lot of Internet traffic. To look up linuxchix.org, your client (or your client's nameserver, most clients will connect to a local nameserver and get it to do the work) must first ask the root nameservers what the .org nameservers are, then ask the .org nameservers for the linuxchix.org nameservers, and then finally the linuxchix.org nameservers for the linuxchix.org IP address. This is also potentially a slow process.

Time to live values

In order to solve some of these problems, nameservers and clients are allowed to store the results of their queries for a certain amount of time, known as the "time to live".

Let's look for example at the linuxchix.org time to live, by examining the dig result (I've cut a lot of it out):

This means that the linuxchix.org server's address (A) is 203.7.155.11.

The time to live for this result is the numerical value 86400, meaning that your client can store the results of this query for a maximum of 86400 seconds (24 hours). After 86400 seconds, it must check back with the original servers in case the information has changed.

You can actually see the cache time dropping if you're interested: leave off the @NS2.ANTHILL.ECHIDNA.ID.AU. part of that dig command (NS2.ANTHILL.ECHIDNA.ID.AU is authoritative for linuxchix.org — you can always cache its results for 86400 seconds) and run it repeatedly to see the amount of time your local nameserver is allowed to cache the result dropping off, for example:

If you're interested in the gory details of the process as a whole, look at RFC 1034 and if you're really really interested, all the updates. However, none of this is necessary for the discussion here!

Caching IP addresses

So, if your time to live is set to 86400, and client X asks for your IP address, they will cache it and probably won't ask again for 24 hours. If you change your IP within that 24 hours, client X will not notice because they'll use their cached result. Only after 24 hours will they check again and notice the change.

There's also a second ttl value known as the "negative time to live": the time that errors (like "name not found") can be stored for, but here we're concerned with the positive time to live: the time that answers can be stored for.

Caching nameserver data

There's a further delay if you switch nameservers, as you will most likely do if you switch hosts and you were using your old host's nameservers.

Consider the linuxchix.org lookup process, in which the .org nameservers tell the client what the linuxchix.org nameservers are. Well, the .org nameservers set their own timeout on the nameserver result which seems to be 48 hours (172800 seconds) at the moment for linuxchix.org:

This information that the .org nameservers provide can be cached too, so even if your new nameservers are giving the right answer, clients may be querying the old ones! Additionally, it will take a while (in my experience, about 12 hours) for your registrar to update your parent nameservers in the first place. So that means a delay while they update and a second delay while their time to live causes old data to be cached.

Changing IP addresses

Here's the important lesson to take away from the caching policy:

IP changes are not instantaneous. If you've changed IP addresses but not nameservers, they won't take effect until your time to live is up. If you've changed nameservers and only the new nameservers have the right information, you will need to wait until the parent nameservers update, and then wait out their time to live, which you normally can't control. Be conservative and add 48 hours to your minimum estimate.

What does this mean for you if you switch hosts? Well, it means either downtime for some clients while everything updates, or maintaining two copies of your information for a while, one at the old host and one at the new.

This tends to be a pain for email. The normal solution is either checking two mailboxes or getting the old mailbox to forward to the new. If you have static websites, websites are easy, just have a copy of your files at the old host and the new. If you have dynamic web content this can be a bit harder: you may have to keep two databases in sync for example. In this situation you will want to do a fair bit of preparatory work and also make sure the IP address change happens as fast as possible.

Changes without downtime

In an ideal situation (where you control the time to live value and can point nameservers wherever you want), here's how you change your IP address as fast and painlessly as possible:

1. first make sure that mail arriving at the old host won't get lost and web queries to the old host will get an appropriate answer, as above. Test that both the old and new sites are working to your satisfaction before beginning the move.
2. a few days before the move, drop your time to live value to something small, like 900 seconds (15 minutes) so that clients will only be 15 minutes behind. You can drop it to 0 if you're really sure that you don't want any clients to cache any data at all during your move. Note that if your time to live is 24 hours and you do this only 12 hours before the move, some clients may have already cached the old data and won't check again for up to 24 hours.
3. if you're switching nameservers, update the *old* nameservers to point at the new location too, so that clients who query those ones get the new IP.
4. as soon as the new information goes in the nameservers, you can increase the time to live again (you don't care about people caching the *new* information for a while, after all). Leaving the time to live low isn't a good idea: it increases the load on your nameservers, and increases the lookup time for clients because they constantly need to check for updates.
5. after about a week when you can be pretty sure that your parent's time to live is up and everyone is querying the new nameservers, delete all your domain information from the old nameservers. You do this because if a nameserver has it's own information for a domain, it will return it when asked, even if the parent nameserver no longer points to it. There's no reason to let the old nameservers do this.

As you can imagine, there's a lot of ways this process can go wrong. A common one is time to live values being accidentally set too high (if you set it to two weeks and a client caches it, there's no way you can force them to check again within two weeks). A safe default if you can manage it is about 24 hours: 24 hours downtime due to wrong information is seldom a disaster.

In conclusion, changing IP addresses and keeping your domain name is faster and easier than changing URLs and waiting for the entire Web to link to your new site (in my experience, links from old unmaintained pages will stick around for 5 years or so) or changing your email address on all your mailing lists and in your friend's address books. However it isn't trivial, and requires some preparatory work. If it's just you and your personal website and personal email, I'd estimate it would be something like 2 hours work, not counting the setup at the new host which depends on their system. For me and my 15 odd domains with their peculiar setups, and my 10 or so users, switching IP addresses is now a solid day's work.

You should choose your host carefully so that you won't have to do this too often. On the flip-side though, while the process is a bit of a pain, don't let it deter you from switching hosts if your current host isn't providing what you need. The cost of switching is not negligible but in my experience it's nearly always lower than that of staying with an inadequate host.

Buying and owning a domain name: Changing hosts by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.