Why it matters
When you change a record, resolvers that already hold the old answer keep using it until its TTL runs out. With a TTL of 3,600 the change reaches everyone within about an hour; with 86,400, within a day. A resolver may also apply its own cap. That is why a change can look correct from your device and be wrong for the client, and why a mistake can appear up to a TTL after it was made.
Working with it
Lower the TTL (to 300 seconds, for instance) a day or more before a planned change, wait at least the old TTL, make the change, verify, and raise it again afterwards. Very low TTLs permanently increase query volume and reliance on the DNS provider.
How to see it
dig www.example.com A prints the TTL in the answer section, the number before IN, for example 300. Ask the same recursive resolver again a minute later and the number is smaller, because the cached copy ages. Ask the authoritative nameserver directly (dig @ns1.example.net www.example.com A) and you see the full value. Both numbers matter when you plan a change: the first tells how long old answers can survive, the second what you set.
What to check
The TTL of the records you are about to change, and the answer from the authoritative nameserver, not only from a cache.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 1035, Domain names: implementation and specification (www.rfc-editor.org)
- RFC 2181, Clarifications to the DNS specification (www.rfc-editor.org)