Mist Network
DNS Propagation Time: How Long It Really Takes and How to Speed It Up
DNS changes are not pushed anywhere; old answers simply expire from caches. Learn what really controls DNS propagation time and how to make your next change land in minutes.
DNS propagation time is the delay between saving a DNS change and every resolver on the internet returning the new answer. For an ordinary record edit it is usually a few minutes up to the record's old TTL; for a nameserver change it can take up to 24–48 hours, because the parent zone's delegation records are cached for longer.
The word "propagation" is a little misleading. Nothing is broadcast across the internet. Your authoritative DNS server knows the new value the moment you click save. What you are waiting for is thousands of independent caches, at ISPs, public resolvers, routers and operating systems, to throw away the answer they stored earlier and ask again.
Why DNS changes are not instant
Every DNS answer carries a TTL (time to live), a number of seconds that tells a resolver how long it may reuse the answer without asking again. If your A record had a TTL of 3600 when a visitor's ISP resolver looked it up, that resolver can keep serving the old IP for up to one hour after you change it, no matter how fast your DNS provider is.
That is the whole mechanism. Different resolvers fetched your record at different moments, so their copies expire at different moments. This is why one friend sees the new site while another still sees the old one, and why online "propagation checkers" show a patchwork of green and red locations for a while.
How long does DNS propagation take? Typical times
The answer depends on what you changed. The table below shows realistic ranges, assuming caches respect the TTL (most large resolvers do).
| Change | What controls the delay | Typical time |
|---|---|---|
| Edit an A, AAAA or CNAME record | Old TTL of that record | 1 minute – old TTL (often 5 min to 1 hour) |
| Add a brand-new record | Negative caching (SOA minimum) | Instant if nobody queried it; otherwise minutes to an hour or so |
| Change MX or TXT (SPF, DKIM, verification) | Old TTL of the record set | Minutes to a few hours |
| Change nameservers at the registrar | TTL of NS records in the TLD zone | A few hours, up to 24–48 hours |
| Register a new domain | Registry publishing the delegation | Usually minutes |
The "new record" row surprises people. If you, or a tool, looked up app.example.com before it existed, resolvers cached the "does not exist" answer. That negative answer is cached too, for a period derived from the zone's SOA record, as defined in RFC 2308. Avoid testing a hostname before you create it.
Record changes vs nameserver changes
Record changes inside the same zone
When you only edit records, such as moving your site to a new server by updating the A record, you are dealing with one cache layer and one TTL. If the TTL was 300 seconds, practically everyone sees the new IP within about five minutes. This is the fast, predictable case, and it is what happens when you follow our guide on how to point a domain to a VPS.
Nameserver changes
Changing nameservers moves the whole zone to a different DNS provider. Resolvers learn which nameservers are authoritative from the TLD's own servers, and for big TLDs those delegation records commonly carry TTLs of a day or two. You cannot lower that TTL; the registry sets it. That is where the famous "up to 48 hours" comes from.
During that window some resolvers still ask the old provider and some ask the new one. If the two zones are not identical, visitors get different answers. The safe pattern is to recreate every record at the new provider first, check it directly, and only then switch nameservers. If you are deciding whether to move DNS at all, read Cloudflare DNS vs registrar DNS first.
How to speed up DNS propagation (the practical way)
You cannot force other people's resolvers to clear their caches, but you can make sure there is very little cached to wait for. Plan the change like this:
- Lower the TTL in advance — at least one full old-TTL period before the change (for a 1-hour TTL, a few hours before), set the records you will touch to 60–300 seconds.
- Prepare the destination — make sure the new server, mailbox or service already answers correctly, so traffic that arrives early is handled.
- Make the change — update the record. Because caches now hold it for a minute or five, the switch spreads almost immediately.
- Verify from outside — query several public resolvers and the authoritative server directly (see the next section).
- Keep the old target alive briefly — leave the old server running for at least the old TTL plus a safety margin, so stragglers do not hit a dead IP.
- Raise the TTL again — once stable, go back to a longer value such as 3600 to reduce lookups and add resilience.
How to check DNS propagation
Start with the source of truth: ask your authoritative nameserver directly. If it returns the new value, your part is done and the rest is caching. Typical commands:
dig +short example.com A @ns1.yourprovider.com— the authoritative answer.dig +short example.com A @1.1.1.1and@8.8.8.8— what two big public resolvers currently return. The TTL shown in fulldigoutput counts down; when it hits zero, the next query fetches the new value.nslookup example.com— available on Windows when dig is not.dig NS example.com +trace— follows the delegation from the root, useful to confirm a nameserver change at the TLD level.
Global "DNS propagation check" websites run the same queries from many countries. They are handy for a visual overview, but remember they reflect a handful of resolvers, not every ISP.
Clearing your own caches
Often the stale answer is on your own machine. Flush the OS cache (ipconfig /flushdns on Windows, sudo resolvectl flush-caches on many Linux systems, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS), restart the browser, or test on mobile data to bypass your home router.
Example: moving a site to a new server
Say you are moving a site from old shared hosting to a new VPS, and your A record currently has a TTL of 3600 seconds. A zero-downtime timeline could look like this:
- Monday morning: lower the TTL of the A and www records to 300 seconds. Wait at least one hour for the old one-hour caches to drain, or do the switch the next day to be safe.
- Before the switch: copy files and the database to the new server and test the site on the new IP using your computer's hosts file.
- Switch: update the A record. Since caches hold it for five minutes at most, traffic starts flowing to the new server within minutes.
- Next day: once the old server's logs show no more visits, shut it down and raise the TTL back to 3600.
For database-driven sites, pause writes such as comments or orders briefly during the switch; otherwise the last few entries that land on the old server may never reach the new one. If you are moving email, apply the same logic to MX records and keep the old mailbox open for a few days.
Common propagation problems and fixes
- Works for you, not for others — check the authoritative server; if it is correct, you are waiting on caches. If not, the record was saved in the wrong zone or provider.
- Still old after 48 hours — usually the domain is using different nameservers than the ones you edited. Compare the NS records at the registrar with where you made the change.
- Email bouncing after a move — MX, SPF and DKIM records were not copied to the new zone before the nameserver switch.
- SSL certificate fails to issue — the certificate authority's validation hit the old IP, or a CAA record blocks it. Wait for the TTL and retry.
DNS propagation time on mistREG
Domains registered at mistREG get their DNS zone hosted on Cloudflare's authoritative network and managed from the mistREG panel, so edits are live on the authoritative servers almost immediately. You can choose any TTL from 60 to 86,400 seconds or leave it on "auto", which makes the lower-the-TTL-first routine above easy to follow.
Records are served in DNS-only mode, which means the IP you enter is exactly the IP visitors receive. If you prefer your own nameservers you can set custom ones at any time; the domain then leaves the Cloudflare-hosted zone and the usual nameserver propagation window applies. You can search for a domain across 200+ TLDs, read the FAQ, or reach support on Telegram at @mistnetwork or through the in-panel ticket system. As always, use of the service is subject to the provider's terms.
