DNS Changes That Take Effect Tomorrow

Nothing is propagating

The word suggests a change spreading outward across the internet, arriving in different places at different times.

What actually happens is that your change takes effect immediately at the source, and everybody else is still holding an older answer they looked up earlier.

Those older answers sit in caches at internet providers, offices, and devices, and each expires on its own schedule.

So the delay is not distribution, it is expiry, and understanding that changes what you can do about it.

The setting that controls it

• Every record has a time to live.
• It is a number of seconds.
• Caches hold the answer for that long.
• Common defaults are one hour or four.
• You can change it before a move.

The last is the whole practical lesson. A record with a four-hour time to live can leave people seeing the old answer for four hours after a change, and lowering it beforehand shortens that window to minutes.

Lower it before, raise it after

Which is the procedure nobody is told about.

Two days before a planned change, set the time to live on the records you will change to five minutes.

Wait for the old longer value to expire everywhere, which takes as long as that old value.

Then make the actual change, which now takes effect for everybody within about five minutes.

Once you are satisfied it worked, raise it back to an hour or more, since a very short value means more lookups than necessary.

That sequence turns a day of uncertainty into a few minutes of it.

A worked example

A business moved hosting and made the change on a Monday morning.

For the rest of that day some customers reached the new server and some reached the old one, and the office computers were split between them.

Two forms submitted to the old server were never seen, since nobody was checking that inbox.

The following move, a year later, they lowered the time to live two days ahead.

The change took effect within about ten minutes and the old server stayed running for a week regardless.

The preparation was two minutes and it removed the entire problem.

Why it works on your phone and not your computer

Which is the confusing symptom.

Your phone on mobile data is using a different provider's cache from your office computer.

Those two caches looked up the record at different moments, so they expire at different moments.

Your own computer also caches independently, and so does your browser, which is why restarting a browser sometimes appears to fix it.

None of that indicates a problem, and all of it resolves on its own within the old time to live.

Checking from a phone on mobile data is a useful second opinion, and it is not authoritative either.

Keep the old server running

Which is the protection that matters more than the timing.

Whatever the caches do, anybody still reaching the old server should find a working site rather than nothing.

So leave the old hosting active for at least a week after a move, and check its logs for anything still arriving.

That converts a split period from an outage for some people into a slightly stale experience for a few.

Watch the old inbox too, since form submissions can land there for days.

Cancelling the old account on the day of the move is the mistake that turns a smooth change into an incident.

Checking what is actually live

Since your own machine is a poor witness.

Free lookup services query the record from many locations and show you what each one currently returns.

That tells you how far through the change you are, without guessing from your own experience.

They are also the fastest way to confirm a change was saved correctly at the source, which is a different question from whether it has reached anybody.

Use one before assuming a change failed, since most apparent failures are unexpired caches.

Some changes are effectively instant

Worth knowing so you do not wait unnecessarily.

Adding a record that did not exist before takes effect almost immediately, since nothing has cached an absence in the same way.

Changing an existing record is the case where the old value has to expire.

Adding a new subdomain, or a verification record for a service, is therefore usually quick.

Changing where your site points is the slow one, and that is the one to prepare for.

Make the change early in the week

A scheduling point that costs nothing and prevents most of the trouble.

A change made on a Friday afternoon spends the weekend half-applied, with nobody watching and nobody available to fix whatever went wrong.

Tuesday morning gives you the rest of the week to notice a problem, reach whoever set it up, and check that forms and email are still arriving.

The same applies to the day before a holiday, which is the version of this that catches people in December.

Nothing about the technology requires this and everything about being able to respond does.

The counter-case

Some caches ignore the rules.

A few internet providers hold records longer than instructed, so a small number of people can see an old answer well beyond the stated time.

Lowering the time to live also increases lookup volume slightly, which matters at large scale and not at yours.

And for a change that is not urgent at all, simply making it and waiting a day is a perfectly reasonable approach.

Lower the time to live two days before a planned change, make the change, keep the old server running a week, and raise it afterwards.

The sequence

1. Note the current time to live.
2. Lower it to five minutes, two days ahead.
3. Wait for the old value to expire.
4. Make the change.
5. Check from a lookup service.
6. Keep the old server a week.
7. Raise it back afterwards.

Step six is the one that matters most, since a change that takes six hours to reach everybody costs nothing at all if the old server is still answering correctly.

The full move is covered in migrating without any downtime.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.