DNS TTL Explained: Why Your Record Changes Take So Long to Apply
TTL (Time To Live) is a value in seconds attached to every DNS record, telling resolvers how long they may cache the answer. A TTL of 3600 means no resolver will ask your nameserver again for an hour — every query in that window gets the cached answer, even if you changed the record a minute ago.
TTL in practice: the migration playbook
- Before a server migration: lower the TTL of the A record to 300 seconds or less — at least one full TTL before you plan to change anything. Doing this an hour before the switch is already too late if the old TTL was 24 hours.
- During the change: update the record. Resolvers worldwide pick it up within the (now short) TTL.
- After the migration is stable: raise the TTL again to several hours or a day. A permanently low TTL doubles or triples your DNS query volume and adds a small latency to every first visit.
- Rarely-changing records (NS, MX): TTLs of hours or days are perfectly fine — until you need to change them, at which point the same playbook applies.
When propagation refuses to end
Two things make “the TTL expired but some users still see the old site” happen. First, negative caching: a failed lookup for a record is itself cached (the SOA minimum TTL), so a typo you fixed can linger. Second — and this is the one that surprises people — some resolvers simply do not obey TTLs strictly and hold answers a bit longer, particularly on ISP networks. There is nothing you can do from the zone side; those caches age out on their own schedule.
This is why checking propagation from multiple geographic points is the only reliable confirmation: it answers “what does the world see right now”, not “what does my resolver see”. The WhoDNS propagation tool queries your record from many locations at once and highlights which resolvers still serve the old value, so you know whether the change is done or the caches need more time.
🔗 Related tool: Check DNS propagation worldwide