# DNS propagation explained: TTL, caches and what it means > DNS changes do not spread outward; caches expire. What propagation really is, how TTL and negative caching set the delay, and how to check. - Canonical HTML page: https://dodomain.io/glossary/dns-propagation - This Markdown twin: https://dodomain.io/glossary/dns-propagation.md - Site index for agents: https://dodomain.io/llms.txt - Full documentation as Markdown: https://dodomain.io/docs/llms-full.txt Generated at build time from the same React source the HTML page renders, never a hand-maintained second copy. Every public page on this host has a twin at `.md`. --- [Glossary](https://dodomain.io/glossary) ## DNS propagation DNS propagation is the everyday name for the delay between changing a DNS record and every resolver returning the new value. Nothing is pushed anywhere: the delay is caches expiring at the end of the record's TTL. Also called: DNS propagation delay, DNS propagation time ### Nothing actually propagates When you save a record, your DNS host writes it into the zone and its authoritative nameservers start answering with the new value almost immediately. That part takes seconds. What takes time is everyone else's memory. Recursive resolvers, the ones run by ISPs, companies and public services like 1.1.1.1 or 8.8.8.8, cache every answer for the TTL it came with. A resolver that asked an hour ago may keep serving the old value until that TTL runs out, and nobody can expire its cache from outside. A resolver that never asked gets the new value on its first query. That is why a change can look live to one person and stale to another in the same minute, with nothing wrong anywhere. ### TTL sets the worst case A TTL is a number of seconds attached to every answer. It is a ceiling, not a schedule: each resolver's clock starts when it asked. For a changed record, the worst-case wait is the previous TTL, because that is the promise resolvers were given about the old value. - Lower the TTL on the records you plan to change, for example to 300 seconds. - **Wait one full old TTL**, so every cached copy of the old promise has expired. - Make the change. The worst case is now five minutes. - Raise the TTL again once the new value is stable. ### Negative caching and nameserver changes Absence is cached too. If a resolver asks for a name before you create it, it caches the "no such name" answer for a period set by the zone's SOA record (RFC 2308). Creating the record then seems to do nothing until that negative answer expires: 15 minutes at the median of the zones we measured, but anywhere from one minute to two days (see [the TTLs we measured](https://dodomain.io/guides/dns-propagation-times)). Looking a record up before it exists is the most common way to make a new record "slow". Changing nameservers is the slow case. The delegation lives in the parent zone at the registry, with a TTL you cannot lower: two days for .com, .net and .uk, between 15 minutes and a day for the other top-level domains we measured. Keep the old DNS host serving correct records until the change has settled. The [registrar vs DNS host](https://dodomain.io/glossary/authoritative-vs-registrar) entry explains where that delegation lives. ### What "propagated" should mean A useful definition has two parts: the authoritative nameservers return the new value, and the public resolvers you care about agree with them. A check that polls only public resolvers can call a record propagated while the source is wrong, or call it stale while the source is already right. The [DNS propagation checker](https://dodomain.io/tools/dns-lookup) reads one record from the zone's authoritative nameservers and from Cloudflare, Google and Quad9 at once and says whether they agree. It does not claim to poll the world: geographic maps matter only for setups that deliberately answer differently by location. ### When it is not caching If the authoritative answer itself is wrong, waiting will not help. The usual causes: editing records at a DNS host that is not the one the domain is delegated to, a proxy rewriting the answer, a record created at the wrong name because of a missing trailing dot, or a stale record left beside the new one. ### Related - [DNS propagation checker](https://dodomain.io/tools/dns-lookup) Compare the authoritative answer with three public resolvers for any record. - [Registrar vs DNS host](https://dodomain.io/glossary/authoritative-vs-registrar) Why records edited in the wrong place never appear, however long you wait. - [DNS provider detector](https://dodomain.io/tools/provider-detector) Check which host actually serves the zone before you wait on a change made elsewhere. - [How long does DNS propagation take? The TTLs we measured](https://dodomain.io/guides/dns-propagation-times) Delegation and negative-caching TTLs read from 15 top-level domains and 36 zones. - [Add DNS records at Namecheap](https://dodomain.io/docs/guides/dns-providers/namecheap) Where to add the record at Namecheap, then how long to wait before checking it. - [Add DNS records at Vercel](https://dodomain.io/docs/guides/dns-providers/vercel) The A and CNAME values Vercel domains expect, and what to check afterwards. ### Frequently asked questions #### How long does DNS propagation take? For a changed record, at most its previous TTL, which is often between five minutes and a day. A new record is visible at once unless a resolver cached its absence, in which case it waits out the zone's negative TTL: a median of 15 minutes across the zones DoDomain measured. Nameserver changes can take up to two days on .com, .net and .uk, because the delegation TTL at the registry is long and not yours to change. #### Why do I see the new DNS record but my colleague does not? Your resolvers cached at different times. Yours asked after the change; theirs asked before and is still inside the old TTL. Operating-system and browser caches can add to it. #### Can I make DNS propagate faster? Not after the fact: nobody can expire another operator's cache. Before a planned change, lower the TTL and wait one full old TTL; the change itself then settles within the new, shorter TTL. #### What does a DNS propagation checker actually check? It queries a record from several places and compares the answers. A useful one includes the zone's authoritative nameservers, which hold the true value, rather than only polling public resolvers. ### Start on the free plan No card, no sales call: create an app, mint a session, and watch the first domain verify. [Start with 50 free](https://app.dodomain.io/signin?mode=signup) [Read the quickstart](https://dodomain.io/docs)