Why a DNS change does not show up everywhere at once, how long to expect depending on the TTL, how to plan a switchover without downtime and how to confirm the change has taken effect.
By Mouhamed BANKOLE, CEO at ITNET Technologies · Updated November 2, 2026 · Reading time: 9 min
You have just edited a DNS record, switched hosting providers or pointed your domain at a new server, and your site still loads from the old address on your machine but not on a colleague's. That is DNS propagation: a normal delay, but one that is often misunderstood. This guide explains what actually happens, how long to expect depending on the TTL, how to prepare a switchover so nobody notices, and how to clear the caches that still show you the old version. You will also know what to check when the change still has not appeared after a full day.
In short
- DNS propagation is not a broadcast: each resolver keeps the old answer in cache until its TTL expires, then queries your zone again.
- The maximum delay normally equals the TTL of the record you changed: 5 minutes with a 300-second TTL, 24 hours with 86,400 seconds.
- The "24 to 48 hours" rule is a safety margin, mostly useful for a name server (NS) change or a domain transfer.
- For a switchover without downtime, lower the TTL at least one old TTL ahead of the change, update the value, then raise the TTL again once everything is confirmed.
- To see the change on your own device, flush the browser and operating system DNS caches, then check against several public resolvers.
Contents
- What is DNS propagation?
- How long does DNS propagation take?
- What role does the TTL play?
- Which caches delay a change?
- Which changes take the longest to propagate?
- How do you prepare a DNS change without downtime?
- How do you flush the DNS cache on your computer?
- How do you check whether propagation is complete?
- What if the change still does not show up?
What is DNS propagation?
DNS propagation is the period during which resolvers around the world keep serving the old value of a record, because they have it cached, before asking your DNS server for the new one. Despite the name, nothing is "pushed" across the Internet: as CaptainDNS puts it, resolvers serve their cache until the TTL expires, then query the authoritative server again.
The path of a DNS query, simplified:
- your browser asks your computer's operating system for the address of
yourdomain.com; - the system queries a resolver (your router's, your company's or a public one);
- if the resolver has no cached answer, it goes up to your domain's authoritative server, the one hosting your DNS zone;
- the answer is stored at every step for as long as the TTL allows.
Your change is therefore visible immediately on the authoritative server. What takes time is every intermediate cache gradually forgetting the old answer. For a refresher on who owns your zone and records, our domain name guide explains the role of the DNS zone.
How long does DNS propagation take?
In most cases, propagation lasts at most the TTL of the record you changed: a few minutes with a short TTL, up to 24 hours with a one-day TTL. The often-quoted "24 to 48 hours" figure is, according to CaptainDNS, a leftover from the early 2000s that matches no current technical constraint.
There are still cases where a 48-hour margin is wise:
- a name server (NS) change, because that information is also cached at the registry of the extension;
- a resolver that ignores the TTL: some Internet service providers keep data for 24 hours or more even when the TTL has been lowered, as Infomaniak points out;
- a very long TTL already in place before your change, which you cannot shorten retroactively.
| Situation | Delay to expect | Why |
|---|---|---|
| Changing an A, CNAME or MX record with a short TTL | A few minutes | Caches expire quickly |
| Same change with a one-day TTL | Up to 24 hours | The old answer stays valid until the end |
| Changing name servers (NS) | 24 to 48 hours to be safe | Registry-side caching and high NS TTLs |
| Creating a new record | Often immediate | Unless a "no answer" response was cached |
| Brand-new domain name | A few minutes to a few hours | Publication in the extension's zone |
What role does the TTL play?
The TTL (Time To Live) is the time, in seconds, a resolver may keep a DNS answer in cache; it sets the maximum duration of propagation. According to Infomaniak, a 24-hour TTL equals 86,400 seconds, during which an IP address change can stay invisible.
Common TTL values and the maximum delay they imply, based on CaptainDNS:
| TTL (seconds) | Maximum delay before the change is seen | Typical use |
|---|---|---|
| 300 | 5 minutes | Just before and during a migration |
| 900 | 15 minutes | Services that change often |
| 3,600 | 1 hour | Common default |
| 14,400 | 4 hours | Stable records |
| 86,400 | 24 hours | Records that almost never change |
The trade-off is simple:
- a short TTL speeds up changes but sends more queries to your DNS server;
- a long TTL eases server load and speeds up lookups for visitors, but makes every fix slow to spread;
- good practice is to keep a medium TTL day to day and shorten it only before a planned operation.
Pro tip: lowering the TTL on the day itself does not help. Resolvers stored the old TTL along with the old answer, so you have to wait for that old TTL to run out before the new, shorter one applies everywhere.
Which caches delay a change?
Four layers of cache can show you an old answer: the browser, the operating system, the resolver (router, company or public) and, more rarely, intermediate forwarders. CaptainDNS identifies the recursive resolver as the most common bottleneck.
What each layer means for you:
- the browser keeps its own DNS table, separate from the system;
- the operating system (Windows, macOS, Linux) caches answers for every application;
- the resolver on your router or company network serves the same answer to all its users, and you cannot flush it yourself;
- public resolvers spread across many sites can return different answers depending on which server replies.
That is why a change can be visible on your phone over mobile data and invisible on the office Wi-Fi: the two are not asking the same resolver.
Which changes take the longest to propagate?
Name server (NS) changes and domain transfers take the longest, because they affect the delegation held at the registry, not just a line in your zone. Next come changes to records that had a high TTL.
Cases to watch:
- NS change: keep the old DNS servers running with an identical zone for 48 to 72 hours, as CaptainDNS recommends;
- MX records: during the transition, some emails may still land in the old mailbox, so keep it active for a few days;
- SPF, DKIM and DMARC: publish the new records before switching MX so deliverability does not suffer;
- DNSSEC: a key error makes the domain unreachable for validating resolvers, which looks like "stuck" propagation;
- cached negative answer: if someone looked up a subdomain before it existed, that "does not exist" answer is cached too, for a duration set by the zone under RFC 2308.
For a domain transfer to Wayhost, the page states that A, MX, CNAME and TXT records are kept exactly as they are and that your site and emails stay online throughout (observed on November 2, 2026 on the French domain transfer page).
How do you prepare a DNS change without downtime?
A seamless switchover takes three steps: lower the TTL in advance, change the value at the chosen time, then raise the TTL once everything is checked. This is the method described by CaptainDNS, with the TTL cut to 300 seconds 48 hours before the operation.
Step by step:
- D-2: note the current value and TTL of every record involved;
- D-2: lower the TTL of the records you will change (to 300 seconds, for example);
- wait at least the old TTL so every cache has picked up the short TTL;
- D-day: bring the new server online and test it without DNS (
hostsfile or direct IP address); - D-day: point the A, CNAME or MX record to the new target;
- D-day: keep the old server running, since some visitors still reach it for a few minutes;
- D+1: check the old server's logs, then raise the TTL back to a medium value.
If you are changing hosts, our guide to moving from shared hosting to a VPS covers the order of operations for files and databases. On the offer side, the Wayhost web hosting page states that your existing site is migrated for you, without interruption (observed on November 2, 2026 on the French page).
Pro tip: schedule a switchover outside your peak hours and never on a Friday evening. If a record is wrong, you want to be able to fix it while the TTL is still short.
How do you flush the DNS cache on your computer?
Flushing the local DNS cache takes one command per system, then one step in the browser; it changes nothing for your visitors, but it shows you your resolver's current answer. The commands below are the ones listed by CaptainDNS.
| System | Command |
|---|---|
| Windows | ipconfig /flushdns |
| macOS | sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder |
| Linux (systemd-resolved) | sudo systemd-resolve --flush-caches (or resolvectl flush-caches) |
| Google Chrome | chrome://net-internals/#dns then "Clear host cache" |
Worth knowing before you run them:
- your router's cache is not cleared by these commands, and restarting the router is not always enough;
- public resolvers sometimes offer a purge page, but it only reaches part of their servers;
- an open browser can hold on to the old address: close it completely or test in a private window.
How do you check whether propagation is complete?
The reliable method is to query the authoritative server directly, then several public resolvers, and compare the answers. If the authoritative server returns the new value, your change is saved; all that remains is waiting for caches to expire.
Useful commands:
dig NS yourdomain.comto find the authoritative servers;dig @<authoritative server> A yourdomain.comto read the value at the source;dig @8.8.8.8 A yourdomain.comanddig @1.1.1.1 A yourdomain.comto compare with two public resolvers;nslookup yourdomain.com 8.8.8.8on Windows ifdigis not installed;- an online checker that queries resolvers located in several countries.
Be careful which test resolvers you rely on from France: Quad9 announced that it will stop serving users located in France on November 24, 2026, following a ruling by the Paris judicial court, according to IT-Connect. If your test scripts or devices use 9.9.9.9, plan for another resolver.
What if the change still does not show up?
If the new value has not appeared once the old TTL has passed, the problem is usually the change itself, not propagation. Start by checking what the authoritative server returns.
Causes to check, in order:
- the change was never saved, or was made in the wrong zone (old host, wrong domain);
- the name servers are not the ones you think: you are editing a zone that is not in use;
- the wrong record type: a CNAME and an A record on the same name conflict;
- a cached negative answer for a subdomain looked up before it was created;
- a DNSSEC error after moving DNS hosting;
- a company resolver that keeps answers longer than the TTL.
If the site still does not respond while DNS is correct, the issue is on the server side: certificate, site configuration or hosting. Our web hosting guide explains what falls to the host. Wayhost DNS management gives you access to A, MX, CNAME and TXT records from one interface, with DNSSEC included (observed on November 2, 2026 on the French domain name page).
Frequently asked questions
What is DNS propagation?
It is the period during which resolvers keep returning the old value of a DNS record because they have it cached. Once the TTL runs out, they ask your domain's server again and get the new value. Nothing is actively broadcast: caches simply expire.
How long does a DNS change take to apply?
Usually no longer than the TTL of the record you changed, from a few minutes to 24 hours. A name server change can take up to 48 hours to be safe. Some Internet service providers also keep answers longer than expected.
Can you speed up DNS propagation?
You cannot force other people's resolvers to clear their cache. However, lowering the TTL at least one old TTL before the change greatly reduces the delay. On your own device, flushing the system and browser caches lets you see the new value sooner.
Why does my site load for me but not for a colleague?
You are probably not using the same DNS resolver, or one of you still has the old answer cached. Your router's resolver, your company's and your mobile carrier's all expire at different times. The difference disappears once the TTL has run out everywhere.
Should you flush the DNS cache after a change?
It only helps you: it lets you see your resolver's current answer. Your visitors will see the change when their own resolver's cache expires. On Windows the command is ipconfig /flushdns.
Which TTL should you choose for a DNS record?
One hour is a good default for most records. Before a migration, drop to a few minutes, then go back to an hour or more once the switchover is confirmed. Records that never change can keep a long TTL.
Does transferring a domain name take the site offline?
Not if the name servers and records stay the same during the operation. A transfer changes the registrar managing the domain, not necessarily the DNS zone. Check before you start that your records will be kept exactly as they are.
How do you find out which DNS servers manage your domain?
Run dig NS yourdomain.com or use an online WHOIS lookup tool. The name servers listed are the authoritative ones. Your changes must be made in the zone hosted on those servers.
Key takeaways
- DNS propagation is caches expiring, not a broadcast: your change is immediate at the source.
- The TTL sets the maximum delay, from a few minutes to 24 hours.
- Lower the TTL in advance and wait out the old TTL before any major switchover.
- Keep the old server running during the transition, especially for the website and email.
- Check at the source with dig before blaming propagation.
To manage your records from one interface and plan switchovers with confidence, explore Wayhost domain name management.
Article written by Mouhamed BANKOLE, CEO at ITNET Technologies.