What is DNS propagation and why does it take so long?

DNS propagation is the period after you change a DNS record during which some people see the new value and others still see the old one. Despite the name, nothing is actually pushed out across the internet. Your change is live on your authoritative nameservers almost immediately, but recursive resolvers around the world have cached the old answer and will keep using it until their cached copy expires. It takes "so long" because those caches are governed by TTL values, which are often an hour or a day, and because nameserver changes at a registrar depend on the TLD's own TTL of up to two days. Most record changes are visible everywhere within minutes to a few hours; nameserver changes can take 24 to 48 hours.

The phrase "allow up to 48 hours for propagation" appears in almost every hosting provider's documentation, and it's frustrating when you're waiting for a site launch. This article explains what is really happening during propagation, the different kinds of change and why they take different amounts of time, the less obvious causes of delay, and practical ways to make changes appear faster.

Propagation Is Really Cache Expiry

To understand propagation, it helps to look at what a DNS change actually does. When you edit a record in your DNS provider's dashboard:

1. The provider updates the zone on its authoritative nameservers. For most modern providers this takes a few seconds, sometimes up to a minute.
2. From that moment, anyone who asks those nameservers gets the new answer.
3. But most people never ask your nameservers directly. Their devices ask a recursive resolver, such as their ISP's resolver or a public one like 1.1.1.1, 8.8.8.8 or 9.9.9.9.
4. If that resolver already has the record cached, it returns the cached copy without asking your nameservers at all.
5. Only when the cached copy's TTL runs out does the resolver fetch the new value.

So "propagation" is the slow, uneven expiry of millions of independent caches. Each resolver started its timer at a different moment, so each one picks up your change at a different moment.

You can see the difference by comparing your authoritative nameserver with a public resolver:

# The authoritative answer: what your zone says right now
dig @ns1.example.com www.example.com A +noall +answer

www.example.com.	3600	IN	A	203.0.113.25

# A cached answer from a public resolver
dig @8.8.8.8 www.example.com A +noall +answer

www.example.com.	2140	IN	A	192.0.2.10

The authoritative server already returns the new address, 203.0.113.25. Google's resolver is still serving the old 192.0.2.10 from cache and will do so for another 2140 seconds, about 36 minutes. Nothing is broken; it's simply waiting for the cache to expire.

Why Different Changes Take Different Times

Not every change is equal. How long it takes depends on what you changed and where the old data was cached.

Type of change	What controls the delay	Typical wait
Editing a record that already exists	The old record's TTL	Minutes to a day, depending on TTL
Adding a brand-new record nobody has queried	Nothing cached yet	Seconds
Adding a record someone queried before it existed	Negative caching TTL from your SOA	Usually minutes to an hour
Changing nameservers at the registrar	The TLD's NS record TTL	Often 24–48 hours
Changing records at a new DNS provider before switching nameservers	No effect until the switch	Not visible yet

Editing an Existing Record

If you change www.example.com from one IP address to another, the maximum wait is roughly the TTL the record had before you changed it. A record with a TTL of 300 seconds is fully updated within about five minutes. A record with a TTL of 86400 seconds can take a full day.

Adding a New Record

A brand-new hostname that nobody has looked up yet has no cached answer anywhere, so it's visible almost as soon as your provider publishes it. This is why adding a new subdomain often seems instant.

The exception is when someone looked the name up before you created it. In that case, resolvers cached a "does not exist" answer, known as NXDOMAIN, and they'll keep returning it until that negative answer expires. The time is controlled by your zone's SOA record. You can check it:

dig example.com SOA +noall +answer

example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026101102 7200 3600 1209600 1800

The final number, 1800, combined with the SOA record's own TTL, sets how long negative answers are cached. Here a premature lookup would delay the new record by up to 30 minutes for that resolver.

Changing Nameservers

Changing nameservers is the slowest kind of change, and it's where the 48-hour warning comes from. When you switch DNS providers, you update the nameservers at your registrar, which then updates the NS records in the TLD zone, such as .com.

Those delegation records have their own TTL, set by the TLD operator, not by you. For .com and .net it's two days:

dig @a.gtld-servers.net example.com NS +noall +authority

example.com.		172800	IN	NS	ns1.oldprovider.example.
example.com.		172800	IN	NS	ns2.oldprovider.example.

172800 seconds is 48 hours. A resolver that cached the old delegation just before your change can keep sending queries to your old provider's nameservers for up to two days. Other TLDs use different values; many country-code TLDs use a day or less.

On top of the TLD's TTL, there's a short delay while your registrar sends the update to the registry, which is usually minutes but can occasionally be longer.

Other Reasons Propagation Seems Slow

Even after the TTL has passed, people often report that a change "still hasn't propagated". Usually one of these is the cause.

Local Caches

Your computer and browser keep their own DNS caches. If you looked up the old address recently, your machine may still be using it even though your resolver has moved on. Querying a public resolver directly with dig bypasses your local cache and tells you whether the problem is on your machine.

Resolvers That Ignore or Stretch TTLs

Most resolvers honour TTLs, but not all of them. Some ISP resolvers apply a minimum cache time, and some serve stale data when they can't reach your nameservers. Large resolvers also run many separate cache nodes, so you may get the new answer on one query and the old answer on the next.

Long-Running Applications

Software that resolves a hostname once and keeps the result, such as some proxies, database drivers and older Java applications, won't see the change until it re-resolves or restarts. This is common with server-to-server connections rather than browsers.

The Old Provider Still Answers

If you move to a new DNS provider but leave your zone active at the old one, resolvers still holding the old delegation get valid, but outdated, answers from the old provider. You won't see errors, just old data, which makes it confusing. Keep the old zone accurate until the switch is complete.

The Change Wasn't Made Where You Think

A surprising number of "propagation" problems are records edited at the wrong provider. If your domain's nameservers point to Cloudflare, editing records in your registrar's DNS panel has no effect. Always confirm which nameservers are authoritative:

dig example.com NS +short

ana.ns.cloudflare.com.
bob.ns.cloudflare.com.

If the result doesn't match the provider whose dashboard you're using, you've found the real problem.

Watching Propagation From the Command Line

You don't need a website to watch a change roll out. A short shell loop can ask several public resolvers for the current answer and remaining TTL:

#!/usr/bin/env bash
NAME="www.example.com"
TYPE="A"

for resolver in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  answer=$(dig @"$resolver" "$NAME" "$TYPE" +noall +answer | awk '{print $2, $5}' | head -n 1)
  printf "%-16s %s\n" "$resolver" "${answer:-no answer}"
done

Sample output part-way through a change:

1.1.1.1          112 203.0.113.25
8.8.8.8          1904 192.0.2.10
9.9.9.9          45 203.0.113.25
208.67.222.222   3011 192.0.2.10

Each line shows the remaining TTL and the address that resolver is handing out. When every resolver shows the new address, the change has reached them.

You can also follow the delegation path from the root yourself with dig +trace, which ignores caches entirely and is useful for confirming a nameserver change at the TLD:

dig +trace example.com NS

.			518400	IN	NS	a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 8 ms

com.			172800	IN	NS	a.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 21 ms

example.com.		172800	IN	NS	ns1.newprovider.example.
example.com.		172800	IN	NS	ns2.newprovider.example.
;; Received 152 bytes from 192.5.6.30#53(a.gtld-servers.net) in 28 ms

example.com.		86400	IN	NS	ns1.newprovider.example.
example.com.		86400	IN	NS	ns2.newprovider.example.
;; Received 112 bytes from 198.51.100.53#53(ns1.newprovider.example) in 17 ms

If the .com servers already list the new provider, the registry side of the change is done, and you're only waiting for caches.

How to Make Changes Appear Faster

You can't force the world's resolvers to drop their caches, but you can make sure they never hold a stale answer for long.

Lower the TTL in Advance

The single most effective technique is to reduce the TTL on records you plan to change, then wait for the old TTL to expire before making the change:

1. Lower the record's TTL from, say, 86400 to 300.
2. Wait at least 24 hours, the old TTL.
3. Change the record's value. Resolvers now pick it up within five minutes.
4. Raise the TTL back once everything is working.

Lowering the TTL at the same time as changing the value doesn't help, because caches already holding the record keep their original countdown.

Prepare the New Provider Before Switching Nameservers

When moving DNS hosting, copy every record to the new provider and check them by querying the new nameservers directly, before you change anything at the registrar:

dig @ns1.newprovider.example www.example.com A +short
dig @ns1.newprovider.example example.com MX +short

Because both providers return the same answers, it doesn't matter which one a resolver uses during the two-day delegation window. Visitors notice nothing.

Don't Test Names Before They Exist

Create records first and test them second. Looking up a hostname before creating it seeds negative caches that delay the result. If you must test early, keep your SOA negative caching value modest, such as 300 to 1800 seconds.

Purge Public Resolver Caches

Cloudflare and Google both provide web pages where you can ask them to purge their cached copy of a specific name. This only helps users of those resolvers, but they're among the most widely used, and it can be useful when you've just fixed a mistake.

Flush Your Own Caches

For your own testing, clear your local caches so you're not fooled by your own machine. On Windows:

Clear-DnsClientCache

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux with systemd-resolved:

resolvectl flush-caches

Why "48 Hours" Is Still Quoted

Many providers tell you to allow 24 to 48 hours for any DNS change. That figure is a safe upper bound that covers nameserver changes at TLDs with two-day TTLs, records with long TTLs, and resolvers that behave badly. For a normal record edit with a TTL of one hour or less, most users see the change within that hour. If you've planned your TTLs properly, a well-run migration rarely needs anyone to wait two days.

---

FAQ: DNS Propagation

---

Conclusion

DNS propagation isn't a mysterious network-wide broadcast. It's the time it takes for resolvers that cached your old records to let those copies expire. Record edits follow the previous TTL of the record, new records appear almost instantly unless a negative answer was cached, and nameserver changes take longest because they depend on the TLD's delegation TTL.

Once you see propagation as cache expiry, you can control most of it. Lower TTLs before planned changes, set up a new provider completely before pointing your domain at it, test against authoritative nameservers rather than your own cached view, and keep old servers running until traffic has moved. With that approach, "allow 48 hours" becomes a worst case rather than an expectation.