DNS propagation and TTL explained

Key takeaways

• DNS changes don’t “propagate”. Your authoritative server changes at once; resolvers keep their cached copy until its TTL runs out.
• The longest you normally wait for a record change is the old record’s TTL, plus any extra caching on devices or in resolvers that cap or stretch TTLs.
• Lower the TTL at least one old-TTL period before a change, make the change, confirm it, then raise the TTL again.
• A brand-new name can stay “missing” because a resolver cached the earlier “doesn’t exist” answer. That wait comes from the zone’s SOA record, not the new record’s TTL.
• Nameserver changes are slower than record changes, because the parent zone’s NS records have their own, often longer, TTL.

Why doesn’t a DNS change show up everywhere at once?

There’s no global DNS synchronization moment — every DNS record is cached independently by whichever resolver last looked it up, each on its own schedule. RFC 8499 defines TTL (time to live) as the maximum time a cached copy of a record should be treated as valid; RFC 1035 specifies TTL as a field published with every resource record, and RFC 1034 describes the caching behavior resolvers implement around that value in more detail (§5, “resolver implementation”). When you change a DNS record, the authoritative nameserver (the one you or your DNS host controls) updates immediately — but every resolver that already cached the old value keeps serving it until that cached copy’s TTL runs out. Cloudflare’s own TTL documentation describes the same tradeoff from an operator’s side: “Time to Live (TTL) is a field on DNS records that controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users.” “Propagation delay” is the sum of however many different resolvers are holding onto a stale cached answer and when each of their individual TTL clocks happens to expire.

example.com.  3600  IN  A  203.0.113.10

That 3600 is the TTL in seconds (one hour). Any resolver that fetches this record will serve it from cache for up to an hour before asking the authoritative server again, even if you change the record five minutes later.

How long should a TTL be?

There’s no single right value; it’s a trade between how quickly a change reaches everyone and how often resolvers have to come back and ask. Common choices look like this:

TTL (seconds)	Longest normal wait after a change	Fits
300	5 minutes	Just before and during a migration or failover
3,600	1 hour	Records that change now and then
86,400	1 day	Stable records: MX, NS, long-lived addresses
604,800	7 days	Rarely sensible; RFC 8767 recommends resolvers cap TTLs at this value

RFC 2181 (§8) adds a detail that explains some “slow” resolvers: a TTL “specifies a maximum time to live, not a mandatory time to live”, and implementations “are always free to place an upper bound on any TTL received.” The standard therefore lets a resolver drop a record sooner than you asked; keeping it longer is outside the standard, apart from the serve-stale case below.

Why do some resolvers seem slower than others?

• Different resolvers cache independently. Your ISP’s resolver, a corporate network’s resolver, a public resolver, and your phone’s mobile carrier resolver have no reason to have cached your record at the same moment, so each is on its own TTL countdown.
• Some resolvers don’t honor TTL precisely. The standard says how long a record should be cached, not a strict enforcement every resolver implementation gets exactly right — a small number of resolvers cache longer than instructed, which looks like “slow propagation” but is really a caching behavior quirk on that specific resolver. Large public resolvers can also cap TTLs downward: the Google Public DNS FAQ says its cached records are generally limited to six hours even if the actual TTL is longer, and it offers a Flush Cache tool for refreshing a stale answer sooner.
• Local caching adds another layer. Operating systems, browsers, and some applications maintain their own short-lived DNS cache on top of whatever the configured resolver returns, independent of the resolver’s own TTL handling.
• A nameserver change is slower than a record change. Changing which servers are authoritative for your whole domain (switching registrars or DNS hosts) depends on the parent zone and every resolver picking up new NS records, which is a different and typically slower process than updating a single A, MX, or TXT record under nameservers that haven’t changed. Getting the new delegation wrong in the process can also leave a lame delegation behind — a listed nameserver that was never correctly configured to serve the zone — which looks like a propagation problem but has a different cause entirely. A registrar transfer close to a domain’s renewal date adds another variable worth ruling out separately — see what happens when a domain expires for how that timeline interacts with DNS changes.

Can a resolver keep serving a record after its TTL expires?

Yes, in one specific case. RFC 8767 (“serve-stale”) lets a recursive resolver keep answering with expired data when it can’t reach the domain’s authoritative servers, so a nameserver outage doesn’t take every cached name down with it. Stale answers go out with a short TTL, with 30 seconds recommended, and the RFC suggests keeping expired records for between 1 and 3 days. A resolver that can reach your nameservers refreshes the record normally, so serve-stale only delays a change while your DNS host is unreachable from that resolver. If your DNS host has an outage in the middle of a change, expect some resolvers to keep the old answer until it is reachable again.

Why does a new record stay “not found” after I add it?

Because “does not exist” is cached too. If anyone, including you, looked up the name before you created it, their resolver received a negative answer and cached it. RFC 2308 sets how long: the negative answer carries the zone’s SOA record, and its cache time is the smaller of the SOA record’s own TTL and its MINIMUM field.

Example SOA (illustrative, documentation names)

example.com.  3600  IN  SOA  ns1.example.net. hostmaster.example.com. (
                  2026111001 ; serial
                  7200       ; refresh
                  3600       ; retry
                  1209600    ; expire
                  900 )      ; minimum = negative-cache time (smaller of this and the SOA TTL)

With this SOA, a resolver that was told “no such name” keeps that answer for up to 900 seconds. Avoid testing a new hostname before you publish it, or expect to wait out that window. A record’s own TTL is distinct from this negative-cache TTL set in the zone’s SOA record; see SOA records explained for that field and the SOA’s other four timers.

How long should you realistically wait?

For an ordinary record change (A, MX, TXT, SRV, CNAME) under nameservers that aren’t changing, expect full visibility within the record’s TTL value, plus a reasonable margin for resolvers that cache slightly longer than instructed — if your TTL was 3600 seconds (1 hour), most of the internet should see the new value within a few hours. A full nameserver (registrar-level) change can reasonably take up to 24-48 hours to be visible everywhere, since it depends on additional caching layers above the record itself (the parent zone’s NS record TTLs, which are often set longer by registries).

How do you make a change with less delay?

1. Lower the TTL in advance. If you know a change is coming, reduce the record’s TTL (for example to 300 seconds) at least one full old-TTL period ahead of time, so by the time you make the real change, resolvers are already re-checking frequently.
2. Make the change.
3. Check with a fresh resolver, not just your everyday network connection — use AdminKit’s DNS lookup to query the record directly against a large public resolver like Cloudflare’s or Google’s, both deployed via anycast, for a fresh, uncached lookup. To see which resolver your own device actually sends queries to, AdminKit’s DNS resolver test page walks through the nslookup comparison.
4. Raise the TTL back to a normal value (for most records, somewhere between 1 and 24 hours is typical) once you’ve confirmed the change is stable, since a very short TTL means more DNS query load and slightly higher latency for every lookup, with no benefit once you’re not actively changing anything.

AdminKit’s DNS propagation check automates step 3 further, querying Cloudflare, Google, Quad9 and OpenDNS at once and reporting whether they already agree, rather than checking one resolver at a time.

Example timeline (illustrative): moving www to a new address, old TTL 86400

Day 1, 09:00   Lower TTL on www from 86400 to 300
Day 2, 09:00   Every cache now holds the 300-second copy (one old TTL has passed)
Day 2, 09:05   Change www A to the new address
Day 2, 09:10   Resolvers have picked up the new address (one new TTL)
Day 3          Confirmed stable: raise TTL back to 3600 or 86400

What if a change still isn’t showing up?

Before assuming propagation is “stuck,” confirm the record was actually published correctly at the authoritative server — a typo or an unsaved change at your DNS host produces the same symptom (“my change isn’t showing”) as a caching delay, but needs a different fix. Query your authoritative nameservers directly (rather than a resolver that might still be caching) to rule this out, then check your TTL value against how long you’ve actually waited before concluding it’s a caching issue rather than a publishing one.

Example commands (documentation names)

dig example.com NS +short                          # which servers are authoritative
dig @ns1.example.net www.example.com A +norecurse  # what the zone publishes now
dig www.example.com A                              # what your resolver still has cached

If the authoritative answer is correct and your resolver’s TTL is counting down, the change is published and you’re only waiting for caches. If the authoritative answer is wrong, fix it at your DNS host; waiting won’t help. For a deeper look at why two resolvers disagree, see DNS answers that differ between resolvers.

Which related checks are worth running?

TTL and caching are one layer of why a DNS change can look wrong; two unrelated layers worth ruling out separately are an open zone transfer leaking more than intended, and whether DNSSEC validation (a different guarantee from caching behavior) is involved at all.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.