While the TTL bar has time left, repeat lookups are answered instantly from the cache. When it hits zero, the next lookup fetches a fresh copy and the timer resets to full.
Two ideas do all the work here: a cache stores answers so they can be reused, and a TTL says how long each one may be reused before it has to be fetched again.
Why caching exists
Looking up a name from scratch means walking the hierarchy, as the guide on what a DNS resolver is describes: root, then the top-level domain, then the domain's own server. That is fast, but doing it for every single request, including the dozens of names a single web page pulls in, would be wasteful and slow.
So every layer keeps a cache. Your browser caches, your operating system caches, and the resolver caches most of all. The first lookup for a name does the full walk; for a while after that, the same answer is handed back instantly without leaving the machine. Caching is the difference between DNS you notice and DNS you do not.
What TTL actually is
TTL stands for “time to live,” and it is simply a number of seconds attached to every DNS record by whoever owns the domain. It is best read as a permission slip: you may reuse this answer for this many seconds. A record with a TTL of 3600 may be served from cache for an hour; after that, the cache must throw it away and ask again.
Every cache along the path obeys the same number, counting it down independently from the moment it received the answer. That is the whole mechanism. The art is only in choosing the number.
What the numbers mean
| TTL | Roughly | What it is for |
|---|---|---|
| 0 | never cache | Always fetch fresh. Used for names that must not be reused, such as the one-time names a leak test generates, or records mid-change. |
| 60 | 1 minute | Fast failover, load balancing, dynamic DNS. Changes spread within a minute, at the cost of far more lookups. |
| 300 | 5 minutes | A safe, agile default for records you might change soon. Quick to update without hammering the servers. |
| 3600 | 1 hour | The common default for stable records like a site's address. Reused for an hour, light on lookups. |
| 86400 | 1 day | Records that almost never change, such as nameserver records. Minimal traffic, slow to alter. |
There is no single correct value. Each one is a position on the same dial, traded between how quickly a change spreads and how often the record has to be looked up.
The trade-off, and the classic trick
A low TTL means changes take effect quickly, because caches forget the old answer soon, but it also means many more lookups, since the answer expires constantly. A high TTL is the opposite: very few lookups and snappy responses, but a change can take up to the full TTL to reach everyone.
This is why administrators use a well-known move before changing an important record: lower its TTL a day or two ahead of time, say from 3600 down to 300, so that when the change goes live the old answer drains out of caches within minutes instead of an hour. Once the change has settled, the TTL is raised again. You plan the agility in advance, because you cannot add it retroactively.
Why DNS changes feel slow
When you update a record and it does not seem to take effect, nothing is broken and nothing is “propagating” in the sense people imagine. What is really happening is that caches around the world are still holding the old answer until their own copy of the TTL counts down. There is no central switch and no way to reach into every cache and force it to forget.
So the time a change takes to spread is, at most, the TTL the record had before you changed it. That old value is the one still ticking down in everyone's cache. The new low TTL only helps for the next change.
Negative caching
“No such name” is an answer too, and it gets cached with its own TTL. That is why a typo'd or just-created domain can keep returning “not found” for a short while even after it exists: the negative answer is still live in the cache.
Serving stale on purpose
Some resolvers bend the rule for speed: when a record just expired, they hand back the old answer in milliseconds and refresh it in the background. This serve-expired behaviour is part of the resolver setup here, trading a moment of staleness for a never-slow response.
See it for yourself
A resolver shows you the TTL counting down. Ask twice in a row and watch the number drop, that is the cache reusing the answer rather than fetching it again:
$ dig example.com +noall +answer example.com. 3600 IN A 203.0.113.42 $ dig example.com +noall +answer # a few seconds later example.com. 3578 IN A 203.0.113.42
The number in the second column is the TTL remaining in the cache. When it reaches zero, the next query fetches a fresh copy and it jumps back to the record's full value.
It is all one dial
Fast to change, or light on lookups. TTL is just where you set that dial, per record.
Browse the guides