How TTL works
Time to live is a value attached to every DNS record, measured in seconds, that tells a resolver how long it may reuse the answer before asking again. Until that timer expires, everyone using that resolver receives the cached answer regardless of what you have since changed at your provider.
This is why a DNS edit never lands everywhere at the same moment. Your own machine may show the new answer straight away because you cleared its cache; a customer on another network is still being handed the previous answer until their resolver’s copy runs out. There is no button that makes the world forget early. The only control you have is the value that was already published before you made the change.
Why TTL matters
It sets the length of your worst-case outage. Point a record at the wrong server while a long timer is in force and the mistake is cached across the internet for that entire period, with nothing to do but wait it out and answer the phone. The same mistake under a short timer is corrected while you are still on the call.
There is a performance trade underneath as well. Longer timers mean fewer lookups, which is marginally faster and lighter on your DNS provider, and some providers bill by query volume. In practice a lookup is quick and devices cache locally too, so the everyday speed difference for a website is small. The safety difference during a change is not small at all.
Common mistakes with TTL
Lowering the value at the moment of the change is the most common, and it achieves nothing. The old, long value is already sitting in caches around the world, and the new short one only applies once that old copy has expired. The reduction has to be published in advance, further ahead than the length of the value it is replacing.
The opposite mistake is leaving everything on a permanently short timer because it feels safer. That adds constant lookups to records that have not moved in years and gains nothing. The related failure is forgetting to raise the value again after a migration, so a settled record is re-queried endlessly long after the reason has gone.
How to act on it
Plan changes backwards from the timer. Choose the date, publish a shorter value on the records you intend to touch well before it, wait for the old value to age out, then make the change knowing a mistake costs minutes rather than a working day. Raise the value again once the new answer is confirmed and stable.
Keep short timers on records involved in an active move or a failover arrangement, and longer ones on records that rarely change: the A record for your bare domain, the www host, your mail routing. When a hosting migration is coming, the timer reduction belongs at the top of the checklist, next to taking a full copy of the existing zone.