How long does DNS propagation take?

For a changed record, at most the TTL the old record had, because that is how long resolvers may keep their cached copy. For a nameserver change at the registrar, plan for up to 48 hours with .com and .net, where the delegation records carry a two-day TTL.

Can I make DNS propagate faster?

Not after the change; you can't reach into other people's caches. You can flush your own machine, and Cloudflare (1.1.1.1) and Google Public DNS have pages that purge a name from their caches. The real fix is lowering the TTL a day or two before the change.

Why does a subdomain I just created return NXDOMAIN?

Someone looked it up before it existed and the 'does not exist' answer was cached. Negative answers are cached for the zone's SOA minimum value or the SOA record's TTL, whichever is lower. Wait that long, or query the authoritative server directly to confirm the record is there.

Some resolvers show the new IP and some the old one. Is something broken?

Usually not. They cached the old answer at different times, so they expire at different times. If the authoritative server returns the new value and the stale resolvers' TTLs are counting down, it will converge. If the answers differ indefinitely, look for GeoDNS or a nameserver that still serves old data.

DNS Propagation Time: How Long It Takes and Why

Nothing propagates. Caches expire.

“Propagation” makes it sound like your change travels outward from server to server across the internet. It doesn’t. When you save a record, your DNS provider’s authoritative servers usually serve the new value within seconds. Nothing is pushed anywhere after that.

What you’re waiting for is everyone else’s cache. Every recursive resolver that looked up your name recently (your ISP’s, 1.1.1.1, 8.8.8.8, a company’s internal DNS) stored the answer along with its TTL, the number of seconds it’s allowed to keep it. Until that timer runs out, the resolver answers from its cache and never asks your server. When it runs out, the next query fetches the new value.

Three things follow:

The wait depends on the old TTL, not the new one. Caches were filled under the old record’s TTL. Lowering the TTL in the same edit as the change does nothing for copies that are already cached.
You can’t force it. There’s no “push to all resolvers” button anywhere, because there’s no list of all resolvers.
Users switch at different moments. Each resolver cached your record at a different time, so each one expires at a different time. A period where some people see the new site and some the old one is normal.

There are also caches closer to the user: the browser (Chrome keeps its own), the operating system’s resolver service, and sometimes the home router. They follow the same rules, but they’re the ones you can clear yourself.

How long it actually takes

What you changed	Worst-case wait	Set by
Edited or deleted an existing record (A, CNAME, MX, TXT)	The old record’s TTL	The TTL before your edit
Added a record at a name nobody had looked up	Close to immediate	Nothing is cached
Added a record at a name someone looked up while it didn’t exist	The negative-cache TTL	The zone’s SOA minimum, or the SOA’s own TTL if lower
Added a new type at an existing name (e.g. AAAA where only A existed)	The negative-cache TTL	Same: “no such record” answers are cached too
Changed nameservers at the registrar	Up to 48 hours for .com and .net	The TTL on the delegation in the parent zone, plus registrar processing

If your old TTL was 300 seconds, a record change is done for well-behaved resolvers in five minutes. If it was 86400, it can take a full day, and no amount of checking will make it faster.

The “24 to 48 hours” figure everyone quotes comes from nameserver changes and long default TTLs. For an ordinary record edit it’s usually an overestimate.

Resolvers are allowed to keep records for less time than the TTL, and many cap very long TTLs. A few misbehave and keep them longer. That’s rare enough that it shouldn’t be your first theory.

Step 1: check the authoritative answer first

Before you wait for anything, make sure there’s something correct to wait for. Ask the servers that are actually authoritative for your domain, bypassing every cache:

$ dig +short NS example.com
ns1.dns-provider.example.
ns2.dns-provider.example.

$ dig @ns1.dns-provider.example www.example.com A +norecurse +noall +answer
www.example.com.        300     IN      A       198.51.100.20

If the authoritative server returns the old value, waiting won’t help. The most common reason: you edited records in one dashboard while the domain’s nameservers point at a different provider. Registrars often have their own DNS panel that does nothing once the domain uses Cloudflare or another provider. The nameserver mismatch guide covers how to tell which provider is really in charge.

If you run your own primary and secondary servers, ask each one. A secondary only picks up changes through a zone transfer, which happens when it receives a NOTIFY or when its refresh timer fires, and only if the SOA serial went up. Forget to bump the serial and the secondaries keep serving the old zone. Compare serials:

dig @ns1.example.net example.com SOA +short
dig @ns2.example.net example.com SOA +short

Step 2: see which resolvers still have the old answer

Query public resolvers directly:

$ dig @8.8.8.8 www.example.com A +noall +answer
www.example.com.        2714    IN      A       203.0.113.5

When the answer comes from cache, the TTL column is the time remaining, not the TTL you configured. Run it again a minute later and the number has dropped. That’s how long this resolver will keep the old address before it asks again. Large public resolvers are many separate caches behind one address, so two queries in a row can show different remaining times, or even an old value and then a new one.

The propagation check asks six large public resolvers (Cloudflare, Google, OpenDNS, DNS.SB, NextDNS and AdGuard) at once and shows each one’s answer and remaining TTL, so you can see who has switched and how long the rest have left. It can’t see your ISP’s resolver or a company’s internal DNS. For those, run dig or nslookup from inside that network against the resolver it uses.

If answers differ but never converge, it may not be propagation at all. CDNs and GeoDNS services deliberately return different IPs in different places. The tool flags that pattern (short TTLs, every resolver answering, different values), and the CDN cache vs DNS propagation guide explains how to tell the two apart.

Step 3: rule out your own machine

If public resolvers have the new value and you still don’t, the cache is local:

# Windows
ipconfig /flushdns

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

# Linux with systemd-resolved
resolvectl flush-caches

Chrome has its own cache: open chrome://net-internals/#dns and click “Clear host cache”. Also check the hosts file (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts) for a line someone added during testing and forgot.

Cloudflare and Google let you purge a name from their public resolvers’ caches (one.one.one.one/purge-cache and Google Public DNS’s “Flush Cache” page). That helps users of those two resolvers only.

And if dig shows the new IP but the browser still shows the old site, it isn’t DNS anymore. An open keep-alive connection keeps talking to the old server until it closes, and the browser, a CDN or a service worker can serve old content from its own cache. The HTTP check fetches the page from outside, so you can see what the new server actually returns.

Negative caching: the NXDOMAIN that won’t go away

You create newapp.example.com, it works for you, and a colleague’s machine insists the name doesn’t exist. Usually someone, or something like a monitoring check or a certificate request, looked the name up before the record existed. The resolver got NXDOMAIN and cached that answer too (RFC 2308).

How long it’s cached is in your zone’s SOA record, which comes back with every negative answer:

$ dig newapp.example.com A +noall +authority
example.com.    300     IN      SOA     ns1.dns-provider.example. hostmaster.example.com. 2026100701 7200 3600 1209600 300

The fields after the two names are serial, refresh, retry, expire and minimum. The negative-cache time is the lower of the last field and the SOA record’s own TTL, here 300 seconds. Some zones use an hour or more.

The way to avoid it: create the record before anything queries the name. Don’t point a monitor or start certificate issuance at a hostname you haven’t created yet. If it’s already happened, wait out that time. It’s the same NXDOMAIN visitors see as DNS_PROBE_FINISHED_NXDOMAIN in Chrome, and the NXDOMAIN guide covers the other causes.

Nameserver changes: where the 48 hours comes from

Changing nameservers isn’t a change to your zone. It changes the delegation, the NS records for your domain stored in the parent zone (.com, .net, .kr). Those records have their own TTL, set by the registry, not by you. For .com and .net it is 172800 seconds, 48 hours.

You can see the delegation by asking a .com server directly:

$ dig @a.gtld-servers.net example.com NS +norecurse

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      ns1.new-provider.example.
example.com.            172800  IN      NS      ns2.new-provider.example.

dig +trace example.com shows the whole path from the root down, which tells you whether the registry has the new nameservers yet. How long the registrar takes to send the change to the registry varies by registrar and registry.

Once the parent zone shows the new nameservers, resolvers that cached the old delegation keep asking the old provider until it expires. That’s why moving DNS providers needs a few rules:

Copy every record to the new provider before switching. All of them: MX, SPF and DKIM TXT, verification records, CAA, SRV. Then compare a few names by querying the new provider’s nameservers directly.
Keep the old provider serving the same zone for at least 48 hours after the switch, longer if you can. Some users will be sent there for that long. Deleting the old zone on day one is how people get a day of SERVFAIL or REFUSED.
Don’t edit records during the move, or make every edit at both providers.
If the domain uses DNSSEC, deal with the DS record first. The DS record at the registry has to match keys the new provider signs with. Otherwise validating resolvers, and 1.1.1.1 and 8.8.8.8 both validate, return SERVFAIL. Either remove DS and let it expire before the move, or follow a key rollover procedure both providers support.

Next time: lower the TTL first

The only real way to make a change fast is to prepare before you make it.

A day or two before: lower the TTL on the records you’ll change to something short, like 300 seconds.
Wait at least the old TTL. If it was 86400, wait a full day. Until then, caches still hold the long-TTL copy.
Make the change. The worst case is now about five minutes.
Keep the old server answering until you’re confident traffic has moved. For mail, keep the old server accepting mail for a while too, because sending servers resolve your MX through their own caches.
Raise the TTL back once things are stable.

This doesn’t work for nameserver changes, since you don’t control the parent zone’s TTL. There, the old provider staying up is your safety net. The TTL guide covers what values to use day to day.

When it really is broken

Waiting is the right call when the authoritative answer is correct and the stale resolvers’ TTLs are counting down. It’s the wrong call when:

The authoritative server returns the old value. The change wasn’t saved, was made in the wrong zone, or was made at a provider that isn’t authoritative.
Your nameservers disagree with each other. Compare SOA serials; a secondary isn’t receiving zone transfers.
The old TTL has long passed and no resolver shows the new value. Check the delegation with dig +trace: the registry may still list the old nameservers.
Everything returns SERVFAIL after a nameserver change. Almost always DNSSEC: a DS record that doesn’t match the new provider’s keys.
Answers keep differing between resolvers with short TTLs. Probably GeoDNS or a CDN doing what it’s designed to do.

The DNS lookup shows the current records and their TTLs as public resolvers see them. Check it against what you configured and the problem usually shows itself.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.