Getting things together for my client over the last few weeks involved lots of checklists, planning, and war gaming exercises. Yet there was one small detail that had been glossed over, and is yet very important in today’s interconnected world: DNS.

For those not familiar: DNS is the mechanism that binds your web site and webapps to your digital properties. It is how your web browser knows that bigco.com goes to Big Co. and not Little Co.

(For the technical crowd, yes this is a gross over-simplification, but bear with me).

While there maybe a task on your conveyance checklists for the day 1 cutover activities, I’m willing to bet it is assigned to a group and you are expecting the re-pointing to be instantaneous.

Contrary to popular belief: it’s not

This depends on how the DNS entries are configured, but given the number of systems that reference each other any number of times per second, the results are almost always cached, and multiple times. Your browser will cache it, your ISP will cache it, all the way to the root of the Internet itself.

How long is this cached for?

This will depend on how the original owner has it configured. I’ve seen as short as 5 minutes and as long as 10 days.

What can you do?

When you get close to your cutover deadline, have the networking team that owns the hostnames readjust the caching timer (time to live or TTL in networking parlance) to a much smaller number. This will increase the load on their nameservers, but will be necessary so that when you do cutover, the new information will be propagated everywhere in a much shorter time. Once everything appears to be working both inside (and outside your corporate network), then you can increase that caching time to a longer, more permanent value.

Be sure you start this activity long before the default caching timer normally expires to ensure the new times get picked up. Otherwise, you will cut everything over just to find out your customers are going to the old location still.

cab