DNS propagation:how to check it, speed it up and stop guessing

"DNS propagation" sounds like your change slowly travels around the world. It does not. The change is live on your DNS provider's nameservers the moment you save it. What takes time is everyone else's cached copy of the old answer running out. You cannot force every cache on the internet to refresh, but you can do five useful things: confirm the source answer is right, check what the big public resolvers see, flush the caches you control, ask Google and Cloudflare's resolvers to refresh, and test the new server before DNS catches up. Next time, you can also make the wait much shorter by lowering the TTL in advance.

Here is how it usually goes wrong (a made-up example). Priya moves her online shop to a new host on a Friday evening and points the domain at the new server. Her phone shows the new site. Her laptop shows the old one. A friend in Dubai says the old one too. Convinced something broke, she switches the record back, then forward again an hour later. Now different people see different sites for most of the weekend, and new orders land on both servers.

Nothing was broken. She was watching caches expire. This guide shows you how to tell the difference in two minutes, with commands you can copy.

What propagation really is

Three layers of DNS matter here:

• The authoritative nameservers hold the real records for your domain. When you edit a record at your DNS provider, these change straight away.
• Recursive resolvers are the DNS servers your visitors actually ask: their internet provider's, an office network's, or public ones like 1.1.1.1 (Cloudflare), 8.8.8.8 (Google) and 9.9.9.9 (Quad9). Each one stores answers it has looked up for a while, so it does not have to ask again.
• Your own device and browser keep a small cache too.

Every record carries a TTL (time to live), a number of seconds that tells resolvers how long they may keep the answer. Cloudflare's documentation explains that the TTL controls how long each record is cached, and therefore how long it takes for record updates to reach your visitors.

Think of it like a restaurant that changes its menu. The kitchen switches dishes the moment the chef decides. But printed menus are already sitting on tables, and the waiters only swap them when each one is due for a replacement. The TTL is the date stamped on each printed menu.

Why this matters: if the authoritative answer is right, waiting really does fix it. If the authoritative answer is wrong, you can wait all week and nothing changes.

Why some changes are fast and others are slow

Not every change waits for the same cache.

• Changing an existing record (an A, CNAME or MX) waits for the old record's TTL. Cloudflare's Auto TTL is 300 seconds, so changes there usually reach most people within minutes. GoDaddy's default TTL is 1 hour.
• Changing nameservers is slower. The list of nameservers for your domain is published by the registry for your domain ending (such as .com) as well as by the DNS provider, and those records often have long TTLs that you do not control. That is why Namecheap quotes up to 24 hours (more in rare cases) and GoDaddy up to 48 hours.
• Creating a record that did not exist before has its own trap. If someone looked the name up before you created it, resolvers remember the "this does not exist" answer. RFC 2308 says the time that negative answer is kept comes from the lower of two values in your zone's SOA record: its MINIMUM field and the SOA record's own TTL. So create records first, and test them afterwards.

Some resolvers also cap how long they keep records. Google's Public DNS FAQ says records there "are generally limited to six hours even if the actual TTL is longer."

Before you start

• Know what you changed and what you expect to see: the domain, the record type, and the new value, for example the new server IP from your hosting welcome email.
• A terminal. On macOS and Linux, dig is usually installed or easy to add. On Windows, use nslookup in Command Prompt or PowerShell; the equivalents are shown below.
• Five minutes, plus the patience not to change the record again while you test.

Step 1: Check the authoritative answer first

First, find out which nameservers are in charge, then ask one of them directly. Replace example.com and the nameserver name with your own:

dig +short NS example.com
dig +short A example.com @ns1.your-dns-provider.example

On Windows, the same two checks look like this:

nslookup -type=NS example.com
nslookup example.com ns1.your-dns-provider.example

Read the result like this:

• The authoritative answer shows the new value: your change is correct and live. Anything else you see is cached. Skip to the steps that help you while you wait.
• The authoritative answer shows the old value: the change was not saved, or you edited the records at the wrong provider. This is common when the domain's nameservers point somewhere other than the panel you edited. Fix it there, and waiting will start to help.
• The nameserver answer lists names you did not expect: the domain is still delegated to another DNS provider. Edit the records where the nameservers point, or follow our guide on connecting a domain to hosting.

Step 2: Compare what public resolvers see

Now ask three big public resolvers the same question:

dig A example.com @1.1.1.1 +noall +answer
dig A example.com @8.8.8.8 +noall +answer
dig A example.com @9.9.9.9 +noall +answer

A typical line of output looks like this:

example.com.        287     IN      A       192.0.2.10

The second column is the remaining TTL in that resolver's cache, in seconds. If you see the old IP with 287, that resolver will ask again in under five minutes. If you see the old IP with 3400, you are looking at almost an hour. Run the same command again a minute later and you will see the number counting down, which is a nice way to stop worrying.

Online checkers such as whatsmydns.net show the same thing for resolvers in many countries at once, which is handy for seeing what customers elsewhere get.

Step 3: Flush the caches you control

If the authoritative answer is right but your own computer still shows the old site, clear your local caches.

Windows

Open Command Prompt (as administrator if it refuses) and run:

ipconfig /flushdns

Microsoft's documentation describes this as flushing and resetting the DNS client resolver cache, including negative entries. ipconfig /displaydns shows what is currently cached.

macOS

Open Terminal and run this, then enter your password:

sudo killall -HUP mDNSResponder

That is the command Apple's support article gives for OS X 10.10.4 and later.

Linux with systemd-resolved

Many current Linux desktops, including Ubuntu and Fedora, use systemd-resolved. Run:

resolvectl flush-caches

The manual page describes this as flushing all DNS resource record caches the service keeps locally. Add sudo if your system asks for it.

Chrome and other browsers

Chrome keeps its own host cache. Open chrome://net-internals/#dns, click Clear host cache, then close and reopen the tab. A private window also helps, because it skips cached pages and cookies.

Phones and routers

On a phone, switching airplane mode on and off usually forces fresh lookups. Home routers often cache DNS too; restarting the router clears it. Neither changes what your internet provider's resolver has cached.

Step 4: Ask Google and Cloudflare to refresh

Two of the biggest public resolvers let anyone refresh their cache for a domain:

• Google Public DNS: use the Flush Cache tool at https://dns.google/cache. Google says it refreshes the cache "for common record types and most domain names", and advises flushing the main domain first if the registrar or DNS hosting changed recently. Flush each record type and subdomain you care about separately.
• Cloudflare 1.1.1.1: use the Purge Cache tool at https://one.one.one.one/purge-cache/. Cloudflare says the purge reaches all its data centres within a few seconds.

Be clear about the limit: each tool only refreshes that company's resolver. Visitors on other internet providers still wait for their own resolvers' caches to expire.

Step 5: Test the new server without waiting for DNS

You do not need public DNS to be ready to check the new site. You can tell your own computer, or a single command, where to go.

Option A: a temporary hosts file entry

The hosts file overrides DNS on one computer only. Its location:

• Windows: C:\Windows\System32\drivers\etc\hosts (open Notepad as administrator, then open the file).
• macOS and Linux: /etc/hosts (edit with sudo nano /etc/hosts).

Add a line with the new server IP and both names, then save:

192.0.2.10    example.com www.example.com

Flush your DNS cache (Step 3), open the site, and check pages, logins, forms and checkout. Microsoft notes that the Windows DNS cache includes entries preloaded from the hosts file, so ipconfig /displaydns will show your override.

Quick tip: delete the line as soon as you finish. A forgotten hosts entry is one of the most common reasons someone "still sees the old site" weeks later, or the new site long after a problem was fixed.

Option B: curl with --resolve

For a quick check without editing any files, curl can connect to a chosen IP while still using your real domain name, which also tests the HTTPS certificate:

curl -I --resolve example.com:443:192.0.2.10 https://example.com/
curl -I --resolve example.com:80:192.0.2.10 http://example.com/

A 200 or a sensible redirect means the new server recognises your domain. A certificate error means the new host has not issued a certificate for the domain yet, which often happens automatically only after public DNS points there.

Plan the next move: lower the TTL first

This is the one real way to shorten the wait for record changes, and it has to start before the move.

1. Look up the current TTL of the records you will change (the second column in Step 2, asked at your authoritative nameserver for the full value).
2. At least a day before the move (and in any case longer than the current TTL), lower the TTL of those records to 300 seconds. At Cloudflare, Auto TTL is already 300 seconds, and DNS only records can go as low as 60 seconds on non-Enterprise plans.
3. Wait out the old TTL. Resolvers that cached the record with the old, long TTL have to drop it first.
4. Make the change. Most resolvers now pick it up within about five minutes.
5. Verify with Steps 1 and 2, and keep the old server running for a day or two anyway.
6. Raise the TTL again to something like an hour once everything is stable, so lookups stay fast.

This trick works for record changes. It does much less for nameserver changes, because the delegation records held by the registry are not yours to edit. If you need to change nameservers, do it calmly, early in the week, with the new zone complete, as our nameserver change checklist explains.

Troubleshooting

Some people see the new site and some see the old one

That is normal during the wait. Check the authoritative answer (Step 1). If it is right, leave everything alone and let TTLs expire. Changing records back and forth only restarts the clock.

dig shows SERVFAIL

This is not a waiting problem. The two usual causes are nameservers that do not answer, and DNSSEC validation failing, often because the registrar still has a DS record from the old DNS provider. A quick test: if dig +cd A example.com @8.8.8.8 returns an answer but the same command without +cd gives SERVFAIL, DNSSEC is the problem. Remove or update the DS record at the registrar.

A new subdomain says NXDOMAIN

Check the spelling and that the record exists at the authoritative nameserver. If it does, a resolver probably cached the earlier "does not exist" answer, and it will clear after the negative caching time from your SOA record.

Email still goes to the old server

MX records follow the same TTL rules. Keep the old mailboxes working during the move, and check both old and new for a day or two so nothing is lost.

dig shows the new IP but the browser shows the old site

DNS is fine; something else is cached. Clear the browser's host cache, try a private window, check for a hosts file entry, and purge any CDN or caching plugin on the old site. A browser can also keep an existing connection open to the old server for a short while.

It works at home but not at the office

Company networks often run their own internal DNS, sometimes with its own copy of your records. Ask the IT team to clear their cache or update their internal zone.

More than 48 hours and still the old answer

Then it is not propagation. Recheck which nameservers the domain uses, confirm the authoritative answer, and look for a second A record or an old AAAA record still pointing at the previous host.

The one message worth forwarding

Send this to your developer or hosting support if you are unsure:

"We changed the DNS for example.com to point to the new server. Can you confirm that the authoritative nameservers already return the new value, tell us the remaining TTL on the old record, and check that there is no stale DS, AAAA or second A record? We will keep the old hosting running until all checks pass."

The takeaway: check the source answer first, flush what you control, refresh the public resolvers you can, test with a hosts entry or curl, and lower your TTL a day before the next move.