DNS Propagation Explained: Why It Takes So Long and How to Speed It Up
You changed your DNS records or nameservers hours ago. Your site is still pointing to the old server. Your colleague on a different Wi-Fi network says it looks fine on their end. You have refreshed three times. Something must have gone wrong.
Nothing went wrong. This is how DNS propagation works. The confusion is almost universal among people migrating a website for the first time. And the frustrating part is that most guides explain what propagation is without explaining why you and your colleague see different things simultaneously, and without giving you the practical tools to check status, bypass the wait, and make the next migration take 15 minutes instead of two days.
Why DNS Propagation Takes Different Amounts of Time for Different People
Your DNS change is not broadcasting to the world like a radio signal. There is no central DNS database that updates instantly. What you have done is update one authoritative nameserver — yours. Everything else on the internet learned about your DNS records by caching answers to DNS queries they made at some point in the past. Until those cached copies expire, they keep serving what they already know.
This is the core fact that explains every confusing propagation experience. Your colleague on a different ISP, using a different resolver, who made a DNS query for your domain after the cache had already expired, got the new record. You, on your ISP's resolver that cached your old record eight hours ago with a 12-hour TTL, will not see the new record for four more hours regardless of what the authoritative nameserver says.
The Cache Chain Every Query Travels Through
When a browser needs to resolve a domain, it does not go directly to your nameserver. It works through a chain of caches:
Chrome, Firefox, and Safari all maintain their own DNS cache. Chrome's cache respects TTL but caps entries at 1 minute. You can flush it at chrome://net-internals/#dns.
Windows, macOS, and Linux all maintain a local DNS cache. Flushing it forces the OS to re-query the ISP resolver. On Windows: ipconfig /flushdns. On Mac: sudo dscacheutil -flushcache.
This is the main variable. Your ISP runs a recursive resolver that your OS queries. It caches answers according to TTL but some resolvers cache longer than the TTL instructs. This is outside your control and is the legitimate source of hours-long propagation delays even with a low TTL.
Public resolvers are fast and TTL-accurate. If you change your DNS resolver to 1.1.1.1, you will see propagation complete within minutes of a 300-second TTL expiry.
This is what you changed. It always has the current record. Every resolver that queries it receives the new value. The delay is not here — it is in all the caches above it.
The Specific Scenarios That Confuse People Most
Your developer is likely on a different ISP whose resolver already re-queried your authoritative nameserver. Or they are using Cloudflare or Google DNS directly. Your ISP resolver cached the old record and has not expired it yet.
Your phone is on mobile data, which routes through your carrier's resolver. Your laptop is on home Wi-Fi, which routes through your ISP's resolver. Different resolvers, different cache states. The phone's carrier resolved the record after your TTL had expired. Your home ISP had not.
Not a new problem appearing. Your cache expired and your resolver fetched the current record — which was already showing the new server for other people. You are catching up to a state that existed for hours. Nothing broke. Your cache updated.
Corporate and enterprise networks often run internal DNS caches with refresh cycles of 4 to 24 hours, or they use split-horizon DNS that overrides external records. Employees on VPN route through the company DNS. This is outside your control. Your personal connection at home sees the new record fine.
The Honest Propagation Timeline (TTL Is the Variable, Not Time)
The myth: "DNS propagation takes 24 to 48 hours." Every hosting support chat, every migration tutorial, every YouTube video repeats this. It is the answer support agents give when they do not know your TTL, so they cite the worst-case scenario.
The truth: DNS propagation takes exactly as long as your TTL. Nothing more, nothing less, plus a small margin for resolvers that ignore TTL. The 48-hour figure comes from the era when 86400-second TTLs were the industry default. Most modern DNS providers now default to 3600 (one hour). If you actively lower your TTL to 300 before migrating, propagation is done in under 30 minutes.
| Record Type | Starting TTL | Typical Propagation | Maximum | Notes |
|---|---|---|---|---|
| A record change | TTL was 300s (5 min) | 5 to 30 minutes | 1 to 2 hours | The ideal scenario. Anyone who lowered TTL before migrating gets this experience. |
| A record change | TTL was 3600s (1 hour) | 1 to 2 hours | 3 to 6 hours | Common with modern DNS providers that default to 3600. Acceptable if planned. |
| A record change | TTL was 86400s (24 hours) | 12 to 48 hours | 72 hours | The source of the 48-hour myth. Still common on registrar-bundled DNS with old defaults. |
| CNAME change | Any TTL | Same as A record — governed by the CNAME's own TTL | Same ceiling | CNAME propagation follows the same TTL rules as A records. |
| MX record change | Low TTL | 30 minutes to 4 hours | 24 hours | Email delivery continues to old server during propagation if old MX still exists. |
| NS change (nameserver switch) | Any TTL | 24 to 48 hours | 72 hours | TLD registry controls NS propagation. Cannot be shortened by lowering TTL. |
| TTL reduction (preparation step) | N/A | 1 full old TTL period | N/A | Lower TTL from 86400 to 300? Wait 24 hours before migrating for the change to take effect. |
The One Exception That Does Not Follow TTL Rules
Nameserver changes are different. When you change your nameservers at the registrar, you are updating the NS record at the TLD registry (Verisign for .com, Nominet for .uk, etc.). The TLD registry has its own TTL for NS records — typically 24 to 48 hours — that you cannot control. No matter how low your record TTLs are, a nameserver change always has a minimum propagation window of 24 to 48 hours.
This distinction matters in practice: if you are just moving your WordPress site to a new server but keeping the same DNS provider (Cloudflare, Namecheap DNS, etc.), you only need to change your A record. That takes minutes at low TTL. If you are also switching DNS providers, you need to change nameservers — which takes 24 to 48 hours. The latter is unavoidable. Conflating the two is how people end up with 48-hour expectations for what should be a 15-minute operation. The nameservers guide covers the mechanical difference in full.
Resolver Update Speed Varies Significantly
| Resolver | Update Speed After TTL Expiry | Behavior Notes | Practical Implication |
|---|---|---|---|
| Cloudflare 1.1.1.1 | Sub-1 minute for TTL-respecting updates | Fastest major public resolver. Respects TTL precisely. | Recommend as permanent DNS resolver for faster migrations |
| Google 8.8.8.8 | 1 to 5 minutes for most updates | Generally fast. Occasional outliers where specific records take longer. | Reliable for checking propagation status via dig @8.8.8.8 |
| OpenDNS 208.67.222.222 | 5 to 30 minutes | Mid-range update speed. Large install base especially on business networks. | Useful to check if your office sees the new records |
| ISP resolvers (major carriers) | Minutes to hours — highly variable | Depends heavily on which ISP and which region. Some honor TTL. Some cache aggressively beyond TTL. | The main source of individual variation — why your colleague on a different ISP sees the new site first |
| ISP resolvers (some developing regions) | Hours to days in rare cases | Some regional ISPs have poorly maintained resolvers with aggressive caching that ignores TTL. | Explains rare reports of propagation taking 3 to 4 days even with low TTL |
| Corporate / enterprise DNS | Depends on internal cache refresh policy | Companies often run internal DNS caches on a 4 to 24 hour refresh cycle. Employees on VPN may see old records long after propagation completes. | The most common cause of migration confusion for remote workers during company domain migrations |
The DNS Cache Chain: Every Level That Slows Your Update Down
Most propagation delays are not caused by slow DNS infrastructure. They are caused by caches doing exactly what they were designed to do: hold a copy of a record for as long as the record owner said to hold it. When propagation takes longer than you expected, the question is almost always: what was the TTL on that record before you changed it?
Why Some Resolvers Ignore Your TTL
The TTL value you set is an instruction, not a lock. RFC 1035 specifies that resolvers must not cache records longer than the specified TTL. In practice, some ISP resolvers cache for longer — sometimes significantly longer — than the TTL instructs. This is a resolver misconfiguration on the ISP's side.
I have seen specific regional ISPs cache records for 6 to 8 hours when the TTL was 300 seconds. These are outliers. The majority of modern resolvers honor TTL correctly. But if you are three hours into a migration with a 300-second TTL and one user in a specific region is still seeing the old site, this is almost certainly the cause. You cannot fix it on your end. You can contact the ISP, but practically speaking, waiting it out is the realistic path.
Browser Cache Is the Easiest to Fix
Before assuming ISP resolver delays, flush every browser cache layer. In Chrome, navigate to chrome://net-internals/#dns and click "Clear host cache." Then go to chrome://net-internals/#sockets and click "Flush socket pools." In Firefox, Settings → Privacy and Security → Clear Data → check "Cached Web Content." On Mac, also run sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder to flush the OS layer. On Windows: ipconfig /flushdns in Command Prompt.
After flushing all local caches, if you still see the old site, the delay is in the ISP resolver — not in your machine. At that point, temporarily switching your DNS server to 1.1.1.1 bypasses the ISP resolver entirely and connects you through Cloudflare's fast-updating resolver.
How to Check Propagation Status in Real Time (5 Tools)
Most people checking propagation refresh their own browser and conclude that "nothing has changed." That tells you only what your ISP resolver knows. It says nothing about the 22 other global locations. Proper propagation checking requires querying multiple resolvers simultaneously.
Enter your domain, select record type (A, CNAME, NS, MX, TXT), and it queries from 22 global locations simultaneously. Green checkmarks show locations that have your new record. Red X marks show locations still serving the old value. The geographic spread is immediately visible.
Use this as your primary propagation monitor during a migration. Refresh every 5 minutes to watch the green spread across the map.
Similar to whatsmydns but with up to 100 global locations. Useful when you need to verify propagation in a specific target region that whatsmydns does not cover (Southeast Asia, Eastern Europe, specific South American countries).
toolbox.googleapps.com/apps/dig/ — shows what Google's resolver currently sees for your domain. Useful specifically for verifying Google-indexed records and checking if Google Search Console verification TXT records are visible from Google's infrastructure.
# Check from your current resolver:
dig yourdomain.com A
# Check against Cloudflare (fast resolver):
dig @1.1.1.1 yourdomain.com A
# Check against Google's resolver:
dig @8.8.8.8 yourdomain.com A
# Check TTL remaining on cached record:
dig yourdomain.com A
# Look at second column in ANSWER SECTION — that's seconds remaining
# Check nameservers at TLD level (bypasses ALL caches):
dig NS yourdomain.com @a.gtld-servers.net
# Check MX records:
dig @1.1.1.1 yourdomain.com MX
# Trace full resolution chain step by step:
dig +trace yourdomain.com A:: Check from default resolver:
nslookup yourdomain.com
:: Check against Cloudflare:
nslookup yourdomain.com 1.1.1.1
:: Check against Google:
nslookup yourdomain.com 8.8.8.8
:: Check MX records:
nslookup -type=MX yourdomain.com 1.1.1.1
:: Check NS records:
nslookup -type=NS yourdomain.com 1.1.1.1How to Interpret What You See
If dig @1.1.1.1 yourdomain.com A returns your new IP: Cloudflare's resolver has the update. Most users on public DNS will see the new server. Users on slow ISP resolvers may still be waiting.
If the TLD-level NS check (dig NS yourdomain.com @a.gtld-servers.net) returns your new nameservers: the NS change has fully propagated to the root level. All subsequent resolver queries will be directed to the new nameservers.
If the TTL in the dig output shows 0: that record just expired in this resolver's cache and will be re-fetched on the next query. A zero TTL at the moment you check means propagation is essentially complete for this resolver.
How to Browse Your New Site Before Propagation Completes
You do not have to wait for DNS to propagate before testing your new server. The hosts file on your computer sits above the entire DNS resolution chain. An entry in your hosts file bypasses all resolvers and sends your browser directly to whatever IP you specify. This means you can test the new server fully — including SSL certificates, email forms, WooCommerce checkout, and page builder output — while your ISP resolver is still serving the old site to everyone else.
Method 1: Hosts File Edit (Most Reliable)
This technique works on all operating systems and is the professional-grade way to verify a migration before it goes fully live.
# Open the hosts file in a text editor (requires admin password):
sudo nano /etc/hosts
# Add these two lines at the bottom:
# Replace 123.456.789.10 with your NEW server's actual IP address
123.456.789.10 yourdomain.com
123.456.789.10 www.yourdomain.com
# Save: press Ctrl+X, then Y, then Enter
# Flush DNS cache to make the change take effect immediately:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder # Mac
sudo systemctl restart nscd # Linux with nscdOpen your browser and load your domain. It connects directly to the new server, bypassing all DNS. Test SSL, test login, test forms, test checkout.
:: Right-click Notepad, select "Run as Administrator"
:: Go to File → Open
:: Navigate to: C:\Windows\System32\drivers\etc\
:: Change filter from "Text Documents" to "All Files"
:: Open the file named "hosts"
:: Add this line at the bottom:
123.456.789.10 yourdomain.com
:: Save the file (Ctrl+S)
:: Flush DNS cache in Command Prompt (run as Admin):
ipconfig /flushdnsMethod 2: Temporarily Switch Your DNS Resolver
Changing your computer's DNS resolver to Cloudflare (1.1.1.1) or Google (8.8.8.8) bypasses your ISP's slow resolver and lets you see the new records much sooner. This is less precise than the hosts file because you still depend on DNS, but it is faster to set up and reverses automatically when you revert settings.
On Mac: System Settings → Network → select your connection → Details → DNS → add 1.1.1.1 as the first entry. On Windows: Settings → Network and Internet → Change adapter options → right-click your connection → Properties → Internet Protocol Version 4 → Properties → set Preferred DNS Server to 1.1.1.1.
Revert this setting after your migration is stable — keeping it changed is fine long-term (Cloudflare's resolver is generally faster than most ISP resolvers), but be intentional about it rather than leaving an accidental configuration change in place.
Method 3: Flush Browser DNS Cache
If your DNS server is already updated (dig @1.1.1.1 returns the new IP) but your browser is still showing the old site, the delay is in the browser's local DNS cache:
Chrome: chrome://net-internals/#dns → Clear host cache
chrome://net-internals/#sockets → Flush socket pools
Firefox: Settings → Privacy → Clear Data → Cached Web ContentHow to Make DNS Propagation Faster: The Pre-Migration TTL Protocol
There is one lever you can pull to control propagation speed, and you have to pull it before you need it. TTL is the instruction you give resolvers: "cache this record for this many seconds, then re-query." If you lower your TTL to 300 before you change the record, resolvers will re-query within 5 minutes of your change. If you lower it at the same time you change the record — too late. Resolvers that already cached the old value with a 3600-second TTL will not re-query for another hour.
This is the single insight that separates a 15-minute migration from a 48-hour one.
The Three-Phase Protocol
Log into your current DNS provider. Find your A record (and any other records you plan to change). Change the TTL from whatever it currently is to 300 seconds. Do not change any other values. The record still points to your current server.
This burns off the high-TTL cache. Every resolver that cached your old record at 86400 seconds will re-query within 24 hours and pick up the new low TTL. By migration day, the entire internet is caching your record for only 5 minutes.
If your current TTL is 86400: wait 24 hours after lowering before migrating. If it is 3600: wait 1 hour. The wait must be at least one full old TTL period.
With TTL already at 300, change your A record to point to the new server IP. Monitor propagation at whatsmydns.net. At 300-second TTL, 95% of the internet will see the new record within 15 to 30 minutes.
Keep the old server running during this window. Visitors whose resolvers have not yet expired the old record will still reach the old server. Both servers should be serving the same content until propagation is confirmed complete.
Do not shut down the old server during this phase. The migration is not complete until whatsmydns shows green for all locations.
Once the migration has been stable for 24 hours, raise your A record TTL back to 3600 seconds. Low TTL is appropriate during a migration. In normal operation, low TTL means every DNS query hits your authoritative nameserver rather than being served from cache — measurably slower DNS resolution for first-time visitors and unnecessary load on your nameserver.
3600 seconds (1 hour) is a good standard operational TTL. 86400 is fine for records you change rarely. Never leave 300 as your permanent TTL unless you are actively migrating.
Interactive: Check Your Current TTL and See What It Means
Nameserver Changes vs Record Changes: Why NS Takes Longer
Changing nameservers feels similar to changing an A record. Both are done in a DNS dashboard. Both involve updating a value. But the mechanics are completely different, and the propagation timelines are not comparable.
How NS Propagation Works
When you change your nameservers, you make that change at your domain registrar. The registrar submits the change to the TLD registry (Verisign for .com, IANA for the root). The TLD registry updates the NS record for your domain in their zone file. These NS records have TTLs set by the registry — typically 24 to 48 hours — that you cannot control.
Every resolver in the world that queries for your domain first asks the TLD registry which nameservers are authoritative. Until the TLD-level NS records expire and get updated, resolvers still ask the old nameservers. Lowering your record TTLs to 300 seconds does not affect this at all. The TLD registry holds the NS record and the TLD registry controls its TTL.
When to Change Nameservers vs When to Change Records
This is the right approach for most website migrations. Keep your DNS provider the same, update only the A record value. Fast, predictable, reversible.
Required when changing DNS providers. Set up all records at the new provider before changing NS at the registrar. Verify every record is present before switching.
How to Verify NS Propagation Is Complete
The TLD-level check bypasses every resolver cache and asks the TLD nameserver directly:
# Check NS records at the TLD level (.com zone):
dig NS yourdomain.com @a.gtld-servers.net
# If you see your NEW nameservers in the answer: NS propagation is complete
# If you still see old nameservers: still propagating at TLD level
# For .net domains:
dig NS yourdomain.net @a.gtld-servers.net
# For .org domains:
dig NS yourdomain.org @b0.org.afilias-nst.orgOnce the TLD-level NS check shows your new nameservers, all subsequent queries from any resolver will be directed to your new nameservers. Individual record propagation from that point follows normal TTL rules at your new nameserver. The full picture — including how TTL interacts with nameserver records — is covered in the DNS records guide.
Email During DNS Migrations: The Most Common Mistake
Email breaks during migrations more often than the website itself. The website gives you an immediate visual feedback loop. Email failures are silent until someone reports a missed message — sometimes hours or days later.
The mechanism of email failure during migrations is almost always the same: MX records were either changed at the wrong time, or a nameserver change was made without first verifying that the new nameserver had all the correct MX, SPF, and DKIM records.
The Safe Email Migration Sequence
dig MX yourdomain.com @ns1.cloudflare.com. If you get your MX records back, they are in place.For a full treatment of the DNS records involved in email authentication including SPF, DKIM, and DMARC, the DNS records guide has copy-paste starter records for every major email provider.
The Complete Migration Checklist (Before, During, After)
Run this checklist for every migration regardless of size. Every item addresses a specific failure mode. The pre-migration steps are the ones most people skip because they are preparing, not migrating — and then they regret skipping them when propagation takes 48 hours instead of 15 minutes.
dig yourdomain.com A and checking the TTL column. Only proceed if TTL is 300 or below.| Migration Phase | Action | Why |
|---|---|---|
| 48 to 72 hours before migration | Lower A record TTL to 300 seconds at current DNS provider. Do not change the record value yet, only the TTL. | Starts the cache expiry process. By migration day, all properly-behaving resolvers will re-query within 5 minutes of a change. |
| 24 hours before migration | Set up all DNS records at new DNS provider or nameserver. A, CNAME, MX, SPF, DKIM, DMARC, CAA. Verify each one manually. | Records exist at new nameserver before any traffic is switched. No gap in availability. |
| Migration window: step 1 | Using hosts file technique: point your domain to new server IP locally. Browse the site and confirm it works. Test SSL certificate. | Confirms new server is functional before any public DNS change. |
| Migration window: step 2 | Change A record at current DNS provider to new server IP. (If doing full NS switch, change nameservers at registrar.) | With TTL already at 300, propagation completes globally within 5 to 15 minutes for most resolvers. |
| Migration window: step 3 | Monitor propagation at whatsmydns.net for A record. Wait for green status across all locations before decommissioning old server. | Ensures no visitors are dropped mid-migration. |
| Migration window: step 4 | Send test email to and from your domain. Confirm email delivery is working correctly. | Email is the most fragile part of any migration. Verify immediately. |
| 24 hours after migration | Raise A record TTL back to 3600. Remove hosts file entries from your local machine. | Reduces DNS query load on nameserver. Cleans up local bypass that is no longer needed. |
| One week after migration | Verify all DNS records are correct at new provider. Run MXToolbox full check. Confirm no old server references remain. | Catches any records that were missed in the initial setup. |
The DNS records guide covers the specific records to set up at your new provider in the correct order, including the sequencing that prevents email downtime. For choosing a hosting provider that makes migrations straightforward with one-click staging and migration tools, the best WordPress hosting comparison covers how ScalaHosting and Cloudways both handle migrations differently from standard shared hosting.
DNS Propagation FAQ
Why does DNS propagation take different amounts of time for different people?
Because every person's DNS request travels through a different chain of resolvers, each with its own cached copy of your DNS records. When you visit a website, your browser asks your operating system resolver, which asks your ISP's recursive resolver, which may or may not ask upstream servers. Each resolver caches the record it received for the duration of that record's TTL. Your ISP may have cached your old DNS record an hour ago with a 24-hour TTL. Your colleague's ISP may have cached it with a 5-minute TTL and already re-queried. Same DNS change, different experience. This is normal and expected. It is not a failure. The only variable within your control is the TTL you set before the change — which determines how long resolvers are instructed to cache the old record.
How long does DNS propagation actually take in practice?
For A record changes with a TTL of 300 seconds: 5 to 30 minutes for 95% of the internet. For A record changes with a TTL of 3600 (1 hour): 1 to 4 hours. For A record changes with a high TTL (86400): up to 48 hours. For nameserver changes: 24 to 48 hours regardless of TTL, because NS records are managed at the TLD registry level. The 48-72 hour figure quoted everywhere comes from the era when 86400 was the default TTL across the industry. Modern DNS providers often default to 3600. If you actively lowered your TTL to 300 before migrating, propagation completes in under 30 minutes for virtually all properly-behaving resolvers.
My colleague sees the new site but I still see the old one. Is something wrong?
Nothing is wrong. This is the normal propagation experience. Your ISP's resolver cached your old DNS record with a certain TTL, and that cache has not expired yet. Your colleague is on a different ISP with a different resolver that either cached with a shorter TTL or that had not cached the record recently. Two things you can do immediately: first, change your DNS resolver temporarily to Cloudflare's 1.1.1.1 or Google's 8.8.8.8 (both update much faster than most ISP resolvers) and flush your browser's DNS cache via chrome://net-internals/#dns. Second, use the hosts file technique to bypass DNS entirely and connect directly to the new server — this lets you verify and use the new site before your ISP resolver catches up.
How do I force DNS propagation faster?
You cannot force other people's resolvers to update — that is outside your control. What you can do is reduce the time they are allowed to cache your record. Lower your TTL to 300 seconds at least 24-48 hours before any planned DNS change. When you make the change, resolvers that honored the TTL will re-query within 5 minutes. For resolvers that have already cached the record with the old high TTL, you must wait for that TTL to expire before they will see the new value. This is why lowering TTL in advance is essential — once you have changed the record, it is too late to speed up resolvers that cached the old value with a 24-hour TTL.
What is the difference between changing nameservers and changing DNS records?
Nameserver changes and DNS record changes are completely different operations with completely different propagation mechanics. Changing a DNS record (like an A record) updates a value within your current nameserver infrastructure. Propagation is controlled by TTL and typically takes minutes to hours. Changing nameservers transfers authority over all your DNS records from one provider to another. The NS record is managed at the TLD registry level (Verisign for .com domains), which has its own TTL of 24-48 hours that you cannot control. Even if you lower all your record TTLs to 300, a nameserver change still takes 24-48 hours for the TLD-level change to propagate. If you are just moving your website to a new server and keeping the same DNS provider, change only the A record — not the nameservers.
How do I check DNS propagation from the command line?
Four commands cover most diagnostic needs. To check your A record from your current resolver: dig yourdomain.com A. To check against Cloudflare's resolver specifically: dig @1.1.1.1 yourdomain.com A. To check against Google's resolver: dig @8.8.8.8 yourdomain.com A. To check the TTL currently on the record (the number in the second column is the remaining cache lifetime in seconds): dig yourdomain.com A and look for the TTL value in the answer section. To verify nameserver propagation at the TLD level, bypassing all caches: dig NS yourdomain.com @a.gtld-servers.net. On Windows, the equivalent is nslookup yourdomain.com for the default resolver and nslookup yourdomain.com 1.1.1.1 for Cloudflare's resolver.
How can I test my new site before DNS propagation completes?
Edit your hosts file to bypass DNS entirely. The hosts file on your computer is checked before any DNS query, so an entry there overrides all resolvers. On Mac and Linux: sudo nano /etc/hosts and add a line like 123.456.789.10 yourdomain.com and 123.456.789.10 www.yourdomain.com where the numbers are your new server's IP address. On Windows: open Notepad as Administrator and edit C:\Windows\System32\drivers\etc\hosts with the same line. Save the file and your browser will connect directly to the new server for that domain. This lets you fully test the new server including SSL certificates, email, forms, and checkout. Remove the hosts file entry after migration is confirmed complete.
My DNS change was made 24 hours ago and some people still see the old site. Is this normal?
If your TTL was 86400 (24 hours) before you made the change, yes. Resolvers that cached your record right before you changed it are still serving the old value and will do so until their 24-hour cache expires. The resolvers that cached it several hours before the change already expired and updated. This staggered expiry is why you see the mixed state. With a 24-hour TTL, the last resolver to update could theoretically do so nearly 48 hours after your change. For ISP resolvers that ignore TTL and cache for longer than instructed — a real but rare behavior — it could be even longer. If it has been more than 72 hours and some users still see the old site, check whether the old server is still live and responding. Some hosting providers do not decommission old IPs immediately, so a resolver serving old cached records would still get a valid response.
Why does changing to Cloudflare nameservers take less time than other NS changes?
It does not take less time at the TLD registry level — all NS changes go through the TLD registry and take 24-48 hours for global propagation. What makes Cloudflare feel faster is that Cloudflare's authoritative nameservers and their resolver (1.1.1.1) update immediately once the NS change reaches them, and Cloudflare's resolver has one of the highest global adoption rates, meaning a large fraction of internet users query through it. Once NS propagation completes, those users see the new records almost instantly. The speed you perceive after a Cloudflare NS change is Cloudflare's resolver infrastructure updating quickly after NS propagation completes, not the NS propagation itself being faster.
Should I keep the old server running during DNS propagation?
Yes. Keep the old server running and responding to requests for the full duration of propagation plus a safety margin. If your TTL was 300 seconds and propagation completes in 30 minutes, keep the old server running for at least an hour after the DNS change. If your TTL was 86400 and propagation may take 48 hours, keep the old server running for 48-72 hours after the change. Visitors whose resolvers have not yet updated to the new IP will continue visiting the old server. If you shut it down while resolvers are still serving its IP, those visitors get a connection refused error. On shared hosting, the old server is typically decommissioned automatically when you cancel or migrate. Schedule the cancellation to happen after the full propagation window, not immediately after the DNS change.
Where to Go Next
DNS propagation is one piece of a broader migration process. The mechanics of every record type involved — A, MX, CNAME, SPF, DKIM, DMARC, NS — are covered in depth in the complete DNS records guide, including copy-paste starter records for every major email provider and an interactive record builder for your specific setup. That page is the reference you want open during any migration.
If your migration context is WordPress specifically and you want to understand how the server-side configuration affects your site after DNS has propagated, the web server comparison guide covers how LiteSpeed, Apache, and Nginx handle incoming requests differently — which matters when your new host uses a different web server than your old one. And if propagation has completed but you are now seeing 500 errors on the new server, the WordPress 500 and 503 error guide covers every cause and fix, starting with the error log that tells you exactly what went wrong.