What a DNS TTL controls
TTL (time to live) is the number of seconds a DNS record may be cached. A resolver that fetches a record with a TTL of 3600 can keep serving it for up to an hour before asking the authoritative nameserver again. The TTL is set per record by whoever manages the zone.
Inside a cache, the TTL counts down. Query the same resolver twice a minute apart and the second answer shows a TTL about 60 seconds lower, which tells you it came from cache.
Typical values run from 300 seconds for records that change often to 86400 (one day) for stable ones. Resolvers may also cap long TTLs at their own maximum.
Where DNS answers get cached
One answer can sit in several caches between you and the authoritative server, and each counts down its own copy.
- The browser may keep its own short cache of recent lookups.
- On most systems, the operating system caches answers for every application on the device.
- A home or office router often runs a small caching forwarder.
- The recursive resolver, run by your ISP, employer or a public service, holds the cache shared by everyone who uses it.
- Some applications and runtimes keep their own cache for the life of the process and may not follow the TTL. A long-running service can need a restart after a DNS change.
Why DNS "propagation" is cache expiry
Nothing is pushed out when you change a record. Your DNS host's authoritative servers start returning the new value, usually within minutes. Every cache that already holds the old value keeps serving it until its TTL runs out.
So the longest wait is roughly the old record's TTL, counted from when the authoritative servers changed. Resolvers cached the record at different times, which is why some people see the new answer before others.
Changing nameservers can take longer. The NS records for your domain live in the parent zone, and the .com and .net zones publish them with a TTL of 172800 seconds (two days). Resolvers can keep using the old DNS host until that copy expires, so keep the old zone running and correct during the move.
You can clear your own browser and operating system caches, but not every resolver's, so the old TTL is the limit you plan around.
How to lower the TTL before a planned change
A lower TTL only helps once caches have picked it up, so lower it at least one old TTL before the change itself.
Keep the low TTL only for the change window. Resolvers query your nameservers more often, and an outage at your DNS host reaches users sooner because cached copies expire quickly.
- Note the record's current TTL, for example 86400.
- Lower it to 300 seconds at least one full old TTL ahead. With a TTL of 86400, that means a day or more before the change.
- Make the change once that time has passed. Caches now hold the old value for at most five minutes.
- Keep the old server or service running until the short TTL has expired and traffic has moved.
- Check the new value on several public resolvers, then raise the TTL again, for example to 3600 or more.
Negative caching: when "no such name" is cached
Resolvers also cache answers that say a record does not exist. Under RFC 2308, an NXDOMAIN or empty answer is cached for the lower of the SOA record's own TTL and the minimum value inside the SOA record.
This catches people who test a hostname before creating it. A resolver that saw the NXDOMAIN keeps returning it until the negative TTL expires, even after the record exists. Create records before you test them, and check the SOA minimum if you need to know the wait.
$ dig +noall +answer example.com SOA
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. 2026102501 7200 3600 1209600 300
# The last number (300) is the SOA minimum. Negative answers here are cached
# for up to 300 seconds, the lower of 300 and the SOA record's TTL of 3600.