DNS propagation explained

Propagation is cache expiry

When you edit a record at your DNS provider, the authoritative servers begin to answer with the new value, usually within seconds, though some providers publish changes in batches and take longer. Nothing is pushed to the rest of the internet. Recursive resolvers, run by ISPs, companies and public DNS operators, keep a copy of each answer for the number of seconds in its TTL. Until that copy expires, they hand out the old value. A resolver that has never asked, or whose copy has expired, asks the authoritative servers and gets the new value at once.

So 'propagation' is the period during which some resolvers hold old data and some hold new data. Its maximum length is governed by the TTL that the old record carried, measured from the moment each resolver last fetched it. A resolver that fetched the record a minute before your edit will keep the old value for almost the whole TTL, and one that fetched it long ago will update almost immediately.

The layers of caching

• Authoritative servers: hold the zone. With several servers, a secondary can lag the primary until the zone transfer happens; compare SOA serials to see.
• Recursive resolvers: the main source of delay. Large public resolvers have many cache nodes behind a single address, so two queries to the same address can differ for a short time.
• Operating system and browser caches: add their own short holding times, and some applications keep addresses for the life of a process.
• Registry and parent-zone caching of delegation: NS and DS records are cached with the parent's TTL, often much longer than the TTL you set in your own zone.

TTL: the number you control

TTL is set per record set in your zone. A short TTL (a few minutes) means a change reaches everyone quickly but resolvers query your servers more often. A long TTL (hours or a day) reduces load and speeds up repeat lookups but slows down changes. Because the TTL in a resolver's cache is whatever was on the record when it fetched it, lowering the TTL is only effective after the old TTL has passed.

Some resolvers apply their own minimum or maximum TTL, so very short values may be raised, and very long ones capped. Treat the TTL as a strong hint and not a promise.

Negative caching

Resolvers also cache failures. If a name does not exist (NXDOMAIN) or has no record of the requested type (NODATA), the answer may be remembered for the negative-caching time, which is the smaller of the SOA record's TTL and the SOA minimum field (RFC 2308). That is why a hostname that you looked up before creating it may appear missing for a while after you add it. The SOA Lookup shows the effective value.

Why different people see different results

• Their resolvers fetched at different times and so have different amounts of TTL left.
• The service uses geographic or load-based steering, so different resolvers are given different addresses on purpose.
• A filtering resolver blocks the name regardless of what you publish.
• Their device or application has its own cache.
• An authoritative server has not yet loaded the change.

Checking progress

First confirm the authoritative servers: if they do not serve the new value, no amount of waiting will help. The NS Lookup shows whether every server agrees and whether the delegation is what you expect. Then compare public resolvers with the DNS Propagation checker, which asks the authoritative servers and ten named public resolvers and shows each remaining TTL. It does not reveal what a given ISP or office network sees, and it makes no claim about geography.

For several record types at once, use the DNS Resolver Comparison.

Planning a change with minimal disruption

1. Find the current TTL of the record and write down the current value.
2. Lower the TTL to a few minutes at least one old TTL before the change.
3. Bring the new destination up, and test it directly, before changing DNS.
4. Change the record, then check authoritative servers and then resolvers.
5. Keep the old destination serving until one full old TTL has passed after the change.
6. Raise the TTL again once everything is stable.
7. To roll back, restore the old value; the new TTL governs how quickly the rollback is seen.

Special cases

Changing name servers is slower and riskier than changing a record, since the parent's NS TTL controls it and you cannot shorten that yourself; keep both providers serving the zone through the change. Changing DNSSEC DS records has its own ordering rules, covered in DNSSEC explained. For email, a changed MX takes effect for each sender as their cache expires, so keep the old mail host accepting mail for a while.

Web and certificate changes follow the same rule: a new address is reached only as caches expire, and a certificate must already be installed on the new host before traffic arrives. After the change, test from a network that is not your own, since your office resolver may be one of the caches still holding the old value. See also the DNS change checklist.

Written by DNS Tools editorial · Last updated 2026-10-09