TTL (time to live) is a number attached to every DNS record, in seconds. It tells anything that looks the record up how long it may keep the answer before asking again.
That is the whole mechanism behind what people call propagation. Nothing travels anywhere. Records simply expire from caches at different moments, and until they do, the old value is still being served.
Why the timing is counter-intuitive
Suppose your A record has a TTL of 86400; one day. A resolver in another country fetched it an hour ago and will not ask again for twenty-three hours.
You now change the record and, at the same moment, lower the TTL to 300 seconds.
That resolver does not care. It is not going to ask again for twenty-three hours, and when it finally does, it will get both the new record and the new TTL. The lowered TTL helps the next change, not this one.
This is why lowering TTL is a preparation step and not a fix.
The sequence
At least one full old-TTL period before the change, lower the TTL to 300. If the old TTL was a day, that means doing this a day in advance.
Wait. The short TTL has to reach the caches before it means anything.
Make the change. Now every resolver re-asks within five minutes, and the change is effectively immediate everywhere.
Verify from outside your own network. Your own machine is the least reliable place to check, because it may have its own cache and its own resolver.
Days later, raise it back.
Why raise it back at all
Two reasons, and the second is the one people miss.
A short TTL means far more queries, which costs a little performance on every visit. A resolver that must ask before connecting adds a round trip.
More importantly, a long TTL is resilience. If your DNS provider becomes unreachable, records cached with a long TTL keep resolving and your site stays up. Records with a 300-second TTL vanish from the internet within five minutes.
That has been the difference between a provider outage nobody noticed and one that took every customer offline.
Reasonable values
3600 (one hour) is a sensible default for records that change occasionally.
300 (five minutes) during a planned change, and for a few days afterwards.
86400 (one day) for records that essentially never change, MX records pointing at a stable mail provider, TXT records for verification.
Very low values below 60 seconds are mostly wasted. Many resolvers enforce a minimum and ignore anything shorter, so you get the query load without the responsiveness.
Checking the current TTL
dig example.com A
The number in the second column of the answer is the remaining TTL for that cached copy, counting down: not the value you configured. Ask the authoritative server for the configured value:
dig @ns1.example.com example.com A
Using dig and nslookup explains reading the output properly.
The negative TTL
The zone's SOA record contains a value governing how long a negative answer is cached: how long "this record does not exist" is remembered.
This is the explanation for a genuinely maddening situation: you add a record that was missing, and it still appears not to exist for some people. Nobody is caching your new record; they are caching its previous absence.
Which is a good argument for creating records slightly before you need them rather than at the moment something is looking for them.
What TTL does not control
Nameserver changes at the registrar are a different mechanism, governed by the parent zone rather than by your TTL, and they routinely take longer.
So a migration where the nameservers change is a slower operation than one where only records change, regardless of what TTL you set: changing nameservers covers that, and planning a DNS cutover deals with the sequence that avoids needing either to be fast.
Resolvers do not always honour what you set
TTL is a request in place of an instruction, and several things override it.
Many resolvers enforce a minimum, commonly around thirty to sixty seconds, so values below that are quietly rounded up. A TTL of 5 buys nothing.
Some enforce a maximum as well, capping very long values, which means a week-long TTL may be treated as a day.
And browsers cache separately from the operating system, on their own schedule, which is why a change can be visible in one browser and not another on the same machine.
The practical consequence: plan for the TTL you set as a floor in place of a guarantee, and verify against several public resolvers rather than assuming. There is more on asking each one directly in using dig and nslookup.
Different records deserve different values
Treating the whole zone as one number is the usual approach and it is not the best one.
A and AAAA records for a site you may need to move quickly: an hour is a reasonable compromise.
MX records change very rarely and their failure mode is severe, so a long value (a day or more) buys real resilience.
TXT records for verification and sender policy change occasionally and are checked constantly. An hour keeps them responsive without generating pointless queries.
NS records are governed largely by the parent zone rather than by you, so the value you set matters less than for anything else. There is more on that difference in changing nameservers.
What a short TTL costs
Two things, and neither is obvious.
A round trip on first contact. A visitor whose resolver has no cached answer waits for a lookup before the connection begins. On a site people visit repeatedly, a longer TTL removes that wait for most visits.
Resilience. Records cached with a long TTL keep resolving if your DNS provider becomes unreachable. With a five-minute TTL, the domain disappears from the internet within five minutes of that outage.
That second point is the strongest argument for raising TTLs back after a migration, and it is the step people skip. Secondary DNS and what happens when DNS fails deals with the failure it protects against.
Watching a change expire
watch -n30 'dig @1.1.1.1 example.com A +noall +answer; dig @8.8.8.8 example.com A +noall +answer'
The TTL in each answer counts down, and when it reaches zero the resolver fetches again. Watching that happen is the clearest way to understand what propagation actually is, expiry rather than travel.
It is also the honest answer to "has it propagated yet": when the countdown restarts with the new value, that resolver has moved. Understanding DNS propagation covers the wider picture.