DNS propagation checker

See how a record has propagated across resolvers worldwide, including India.

Have feedback or an idea for this tool?

What is DNS propagation?

DNS propagation is the delay between changing a record and every resolver worldwide serving the new value. It happens because resolvers cache each record for the length of its time-to-live, so an old answer can linger until that timer expires. This checker queries the same domain and record type from resolvers in several regions, including India, and shows what each one currently returns, so you can see whether a change has spread evenly or is still rolling out. Enter a domain and a record type such as A or MX to compare the answers side by side. Use it after updating a record to know when a migration is safe to complete, or to explain why some users still reach the old server while others already see the new one.

Key facts

DNS propagation is the period after a record change during which some resolvers still return the old value and others return the new one until their cached copies expire.
A DNS record change is not pushed across the internet; each recursive resolver holds its cached copy until the record's TTL expires and then refetches from the authoritative nameservers.
The OLD TTL in effect when resolvers last cached a record determines how long the stale value lingers, not the new TTL set at the moment of the change.
DNS changes usually settle within a few minutes to a couple of hours, with 24 to 48 hours as the worst case, and nameserver (NS) changes being the slowest.
A DNS propagation checker sends the same query to public resolvers in different regions, such as Google (8.8.8.8), Cloudflare (1.1.1.1) and Quad9, to show which caches have updated.

What DNS propagation actually is

"DNS propagation" is the informal term for the period after you change a DNS record during which some resolvers still return the old value and others return the new one. Nothing is literally being pushed out across the internet - instead, each recursive resolver simply holds its cached copy of your record until that copy expires, then fetches the fresh value from your authoritative nameservers the next time it is asked.

Because resolvers cached your record at different moments and for a duration set by the record's TTL, they expire at different times. That staggered expiry is why a change looks live from one network and stale from another for a while. A DNS propagation checker queries many public resolvers at once so you can watch that rollout complete instead of guessing.

The record only ever has one true value at your authoritative nameservers. Propagation is purely about how long cached copies elsewhere take to catch up.

RFC 1034 - Domain names, concepts and facilities · DNS concepts (RFC 1034)

Why TTL controls how long it takes

Every DNS record carries a TTL (time to live) in seconds. When a recursive resolver answers a query, it caches the record and honours that value for up to the full TTL before it will ask your authoritative nameservers again. A record with a TTL of 3600 can therefore be served from a stale cache for up to an hour after you change it; a TTL of 86400 means up to a full day.

The critical detail for planned changes: it is the OLD TTL - the value that was in effect when resolvers last cached the record - that governs how long the stale copy lingers, not the new TTL you set at the moment of the change. That is why the professional move is to lower the TTL well in advance of a migration.

Some resolvers, and some ISPs, ignore very low TTLs or clamp them to a minimum, so extremely short TTLs do not always behave as advertised. TTL sets the ceiling on cache lifetime, not a guarantee of exact timing.

RFC 2181 - Clarifications to the DNS specification (TTL handling)

How checking from multiple global resolvers works

A propagation checker sends the same query - say, the A record for your domain - to a spread of public recursive resolvers in different regions and networks: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9, OpenDNS and regional resolvers, including ones that answer traffic in India. Each resolver returns whatever it currently has cached, so the results form a snapshot of who has updated and who is still serving the old value.

This matters because your users do not all resolve through the same servers. Someone on a mobile network in Mumbai and someone on a home connection in London may hit completely different resolver caches. Seeing a mix of old and new answers across regions is normal mid-rollout and simply tells you which caches have not yet expired.

For a full record inventory rather than a propagation snapshot, pair this with a plain DNS lookup that returns A, AAAA, MX, TXT, NS, CNAME and SOA in one view.

Typical propagation windows and how to speed them up

In practice most changes settle within a few minutes to a couple of hours. The commonly quoted "24 to 48 hours" is the safe worst case, driven by long TTLs, resolvers that clamp TTLs to a higher floor, and nameserver (NS/registrar) changes, which additionally depend on the TLD registry updating and its own TTLs. Nameserver delegation changes are the slowest kind and are where the 48-hour figure genuinely applies.

To speed propagation up you plan ahead: lower the record's TTL to something short (300 seconds is common) at least one old-TTL period before the change - ideally a day or two early - then make the actual change once the low TTL is itself live everywhere. After the change succeeds and you have verified it, raise the TTL back up to reduce query load. You cannot shorten propagation after the fact, only prepare for it beforehand.

You can force your own machine to see the new value immediately by flushing its DNS cache or querying an authoritative nameserver directly, but that does not affect anyone else's resolver.

Glossary

Recursive resolver: A recursive resolver is the DNS server that answers a client's query by walking the DNS hierarchy and caching the result. Public examples include Google at 8.8.8.8 and Cloudflare at 1.1.1.1.
Authoritative nameserver: An authoritative nameserver holds the true, current records for a zone and is the source resolvers fetch from when their cache expires. It always reflects a change immediately, even while cached copies elsewhere are still stale.
DNS cache: A DNS cache is the local store where a resolver keeps records it has already fetched, for the length of each record's TTL. Cached copies are why a change is not visible everywhere at once.
Old TTL: The old TTL is the TTL value in effect when a resolver last cached a record, and it governs how long the stale value lingers after a change - not the new TTL set at the moment of the edit.
NS delegation change: An NS delegation change moves a domain to different nameservers and is the slowest kind of DNS change, because it also depends on the TLD registry and its own TTLs updating. This is where the 24 to 48 hour worst case usually applies.
Cache flush: A cache flush clears a machine's local DNS cache so it refetches records instead of serving stale copies. It makes your own device see a new value immediately but has no effect on other people's resolvers.

Questions, answered.

What does DNS propagation mean?+

DNS propagation is the period after you change a DNS record during which resolvers around the world gradually stop serving the old cached value and start returning the new one. Nothing is pushed out - each resolver just keeps its cached copy until that copy's TTL expires, then fetches the fresh value from your authoritative nameservers. Propagation is finished when every resolver returns the new value.

How long does DNS propagation take?+

Usually a few minutes to a couple of hours for a normal record change, and up to 24 to 48 hours in the worst case. The actual time depends mostly on the record's old TTL and the resolvers involved. Nameserver (NS) changes are the slowest because they also depend on the domain registry and TLD updating, which is where the 48-hour figure most often applies.

Why does a record show updated in some places but not others?+

Each recursive resolver caches your record for the length of its TTL, and different resolvers cached it at different moments, so their copies expire at different times. Until a given resolver's cache expires it keeps serving the old value. Seeing a mix of old and new answers across regions is completely normal mid-rollout and simply shows which caches have not yet expired.

How can I speed up DNS propagation?+

You cannot speed it up after the change - you prepare beforehand. Lower the record's TTL to a short value like 300 seconds at least one old-TTL period before the change, ideally a day or two early. Once that low TTL is live everywhere, make the actual change; caches will then refresh within minutes. Raise the TTL back afterwards to cut query load.

What is TTL and why does it matter for propagation?+

TTL (time to live) is a value in seconds attached to every DNS record that tells resolvers how long they may cache it. A TTL of 3600 lets a resolver serve a stale copy for up to an hour after you change the record. Crucially, it is the OLD TTL in effect before your change that determines how long stale copies linger, not the new TTL - which is why you lower TTL ahead of a planned migration.

How does checking DNS from multiple locations work?+

A propagation checker sends the same query to many public recursive resolvers in different regions and networks - such as Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 and regional resolvers, including ones serving India - and shows what each currently returns. Because your users resolve through different servers, this reveals which caches have picked up the new value and which are still serving the old one.

How do I check DNS propagation from the command line on Linux?+

Query a specific public resolver with dig, for example "dig @8.8.8.8 example.com A" and "dig @1.1.1.1 example.com A", then compare the answers to the value you set. Run the same query against several resolvers to see the spread. On systems with a local cache, run "sudo systemd-resolve --flush-caches" (or restart the resolver) first so your own machine does not return a stale answer.

Why does my DNS change look live on the tool but not on my own computer?+

Your operating system, browser and often your router keep their own DNS caches, separate from the public resolvers the tool queries. Even after public resolvers update, your device can keep serving the old value until its local cache expires. Flush your DNS cache and, if needed, restart the browser or router to see the new value locally.

Built by the ServerCake team

Cloud that speaks India.

These tools run on ServerCake infrastructure in India. When our cloud opens, you get VMs and managed databases priced in ₹, billed with GST, on India-resident infrastructure. Reserve your spot for early access.

Reserve your spot

More tools

Browse all tools