DNS propagation explained: why half the office still sees the old site

Propagation is not your change spreading: it is the network's saved answers running out their clocks, faster or slower depending on what you set before the change.

The record was changed yesterday afternoon, and this morning half the office still lands on the old site while the other half sees the new one. The launch window is open, the team is watching, and the domain appears to be telling different truths to different people. Nothing is misbehaving. The name system is doing exactly what it was configured to do, months ago, by a setting nobody has thought about since.

The honest mechanism: the answer to what your domain points at is cached at many points between the visitor and the authority that holds the truth. Devices keep copies, networks keep copies, the services in between keep copies, and every cached answer carries a TTL, the length of time its holder may keep it before asking again. Propagation is not your change spreading out into the world. It is those clocks, already ticking, running out one by one, faster or slower depending on what was set before you touched anything.

That reframes the waiting. Nothing is being pushed out to the world; the world is simply finishing the answers it already holds. A change made against a short TTL settles within minutes across most of the network. The same change made against a long TTL, the kind set months earlier for performance and forgotten, leaves hours of old answers in circulation, and there is no way to call them back.

The failure versions stack up around launch day. The change made at the moment of need, against a long TTL set in another season: the move begins exactly when the patience for waiting has run out. The owner who flips the record back and forth within the hour, testing, second-guessing, re-testing, multiplies every cache's confusion, because now some holders have the new answer, some have the older one, and some have the newest one, each with its own clock.

And the most human failure: the colleague who reports it is broken because it is broken on their screen. One device's cache is not the state of the world; it is one device's memory of the world. Diagnosing a migration from the machine that refuses to update is how launches get rolled back for no reason.

The practice is mostly performed before the change. Set a short TTL some time before a planned move, so the old answers expire on your schedule rather than the old schedule. Then make the change once, and resist the urge to touch it again while the clocks run. Verify from a network you do not control: a phone on mobile data beats the office wifi, which has its own opinions saved up. And tell the team, in advance and in writing, that the old answer may survive on some devices for a while, so the first report of the old site is information, not an alarm.

Guidance, not guarantees: we plan the TTL work into every migration we run, and we verify from outside our own networks before calling a move live. The record types and their syntax have their own essay, and the mechanics of editing them belong to your registrar's documentation. What this essay owns is the clock: the change is instant, the world's agreement with it is not, and the gap between the two is a planned stretch of patient waiting, not a defect.