DNS propagation: how long it really takes, and how to check it

Kofi Agyem, Founder and CEO, CloudzyroPublished November 1, 2026 · 6 min read

On this page

1. The short answer
2. Why it isn't really propagating
3. How long each kind of change takes
4. Make planned changes fast
5. How to check propagation with dig
6. Speeding it up after the fact
7. When it isn't propagation
8. Sources

DNS changes don't propagate; cached answers expire. How TTLs decide the wait, why nameserver changes are slower, and how to check with dig.

1. The short answer

DNS propagation is the time it takes for a DNS change to show everywhere. Despite the name, nothing travels outward. Your DNS provider updates the moment you save; resolvers around the world keep using the old answer they cached until its TTL (time to live) runs out, then fetch the new one.

So the wait depends on the old record's TTL. A changed record usually shows within minutes to an hour, a brand new record within a few minutes, and a change of nameservers within a few hours, occasionally a day or two. For the basics, see What is DNS?.

2. Why it isn't really propagating

When you open a site, your device asks a recursive resolver, usually your internet provider's or a public one like 1.1.1.1. The resolver asks the domain's authoritative nameservers, gets the answer and keeps a copy for as many seconds as the record's TTL says. Everyone using that resolver gets the cached copy until it expires.

There are many thousands of resolvers, and each cached your record at a different moment. When you change the record, each one picks up the new value when its own copy expires. That staggered expiry is what people call propagation. It also explains the classic confusion: the site's new for you and old for a colleague, because you're using different resolvers that cached it at different times.

Layers of cache add up. Your browser, your operating system and your router can each hold an answer too, which is why flushing your own caches sometimes helps even after public resolvers have the new value.

3. How long each kind of change takes

A changed record (A, CNAME, MX, TXT): up to the old record's TTL. With a TTL of 3600, up to an hour. With 300, up to five minutes.
A brand new record: usually as soon as it's saved, because nobody has cached it. Unless someone looked it up before it existed (next point).
A name looked up before it existed: resolvers cache the not-found answer too. RFC 2308 sets that negative cache time from your zone's SOA record (the smaller of its last field and its own TTL), commonly between 5 minutes and a few hours.
A nameserver change: usually a few hours, occasionally a day or two. The NS records for your domain live at the registry for .com and the like, which hands them out with long TTLs, often two days, and some resolvers hold them that long.
A new domain: the registry usually publishes it within minutes of registration.

For a site on Cloudzyro Sites & Apps, a new domain usually goes live in 5 to 15 minutes, though DNS changes can take a few hours with some providers. The site's Domains tab checks for you and says when your record is in place but still reaching the rest of the internet.

4. Make planned changes fast

A day ahead, lower the TTL of the records you'll change to 300 seconds. Wait at least the old TTL so caches pick up the short one.
Make the change. Most resolvers now see it within five minutes.
Check it against your nameserver and a few public resolvers (below).
Raise the TTL again, to 3600 or more, once you're happy.

When moving a site, keep the old server running until the old TTL has passed, so visitors with a cached answer still reach something. On Cloudzyro, a domain that's already serving a live site elsewhere can be moved with no gap: the domain card's Moving a site that's already live at this domain? section gives TXT records to add first, so the certificate is ready before you switch the CNAME. See the custom domain docs.

5. How to check propagation with dig

Start with the source of truth, the domain's own nameserver. Then compare public resolvers.

# 1. Which nameservers hold the domain?
dig +short NS example.com

# 2. Ask one of them directly: this is what everyone will eventually see
dig www.example.com @ns1.yourprovider.com

# 3. Ask public resolvers: the second column is the TTL left in their cache
dig www.example.com @1.1.1.1
dig www.example.com @8.8.8.8
dig www.example.com @9.9.9.9

# 4. Follow the chain from the root, bypassing every cache
dig +trace www.example.com

# Windows
nslookup -type=NS example.com
nslookup www.example.com ns1.yourprovider.com
nslookup www.example.com 8.8.8.8

Read the TTL column. If a public resolver still shows the old value with, say, 1740 seconds left, it'll switch in 29 minutes. Run the same command again and you'll see the number counting down. Web tools that query resolvers in many countries at once do the same thing from more places.

If your nameserver shows the old value, the change didn't save, or you edited records at a provider that isn't the domain's nameserver. That's the most common reason a change never shows up.

6. Speeding it up after the fact

You can't flush every resolver, but you can clear the ones you and most people use:

Your own devices: flush the system and browser caches (commands below), and restart your router.
Cloudflare's 1.1.1.1: use its purge cache page.
Google Public DNS: use its flush cache page.

# Windows (Command Prompt or PowerShell)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved (Ubuntu, Fedora and most others)
resolvectl flush-caches

# Chrome's own cache: open this address, then click Clear host cache
chrome://net-internals/#dns

7. When it isn't propagation

If it's been well past the TTL and things still don't work, look elsewhere:

Wrong place. Records edited where the domain's nameservers don't point. Check with dig NS.
Two records on one name. A CNAME can't share a name with any other record. See A record vs CNAME.
Name doubled. Typing www.example.com where the provider adds the domain gives www.example.com.example.com.
A proxy in the way. A Cloudflare record set to Proxied when your host wants DNS only.
DNS is right, the site isn't. The name resolves but the browser shows a certificate warning or this site can't be reached.

For a Cloudzyro site, the domain troubleshooting guide explains each message on the Domains tab, and How to point a domain at your site walks through the records.

8. Sources

Questions

How long does DNS propagation take?

For a changed record, up to its TTL, often 5 minutes to an hour. For a brand new record, usually a few minutes. For a nameserver change, a few hours and occasionally up to a day or two, because the TLD's nameserver records have long TTLs.

Can I speed up DNS propagation?

Lower the record's TTL a day before the change, so caches drop it quickly. After the change you can flush your own computer's cache and ask Cloudflare's and Google's public resolvers to purge their copy. You can't flush every resolver in the world.

Why does my site show the new version for me but not others?

Different resolvers cached the old answer at different times, and each one keeps it until its TTL runs out. Everyone sees the new answer once the old TTL has passed for their resolver.

Is DNS propagation the same as cache?

Yes, in practice. Nothing is pushed out. Your DNS provider updates straight away, and resolvers keep using cached answers until they expire. Propagation is the time those caches take to expire.

What is a good TTL?

3600 seconds (one hour) is a sensible default for records that rarely change. Use 300 seconds (five minutes) before and during a planned change. Very low TTLs mean more lookups and slightly slower first visits.

How do I check DNS propagation?

Ask the domain's own nameserver first with dig @ns1.yourprovider.com, which shows the truth. Then ask public resolvers like 1.1.1.1, 8.8.8.8 and 9.9.9.9. When they all match, the change is everywhere that matters.

Why did my new subdomain take longer than its TTL?

If anyone looked the name up before it existed, resolvers cached the not-found answer. That negative answer lasts for the time set in your zone's SOA record, which can be an hour or more.