Free tool
Has my DNS change propagated yet?
You changed an A record, an MX record, a TXT record, and nothing tells you whether it took. This tool asks eight public resolvers, then asks your zone's own name servers, and shows you which ones are still handing out the old answer.
The mechanism
Nothing propagates: copies expire
Change a record and no resolver gets told. Each one keeps the copy it took until THAT copy expires — and it started aging the moment the resolver asked, not the moment you hit save. Drag the clock and watch them let go one at a time.
A resolver that asked just before your change
its copy expires in 1 h203.0.113.10the old valueA resolver that asked halfway through
its copy expires in 30 min203.0.113.10the old valueA resolver that asked shortly before it expired
its copy expires in 9 min203.0.113.10the old valueA resolver nobody had asked about this name yet
no copy to expire198.51.100.25the new value
The second you hit save, three of these four resolvers are still serving the old value, and nothing you do changes that. The fourth had nothing cached, so it picks up the new value right away.
A TTL is a ceiling each cache counts from ITS OWN query (RFC 1035, § 3.2.1). The “up to 48 hours” every host repeats comes from no rule at all: the worst case is the TTL you were publishing before you made the change.
What this check measures, and what it cannot
It queries eight public resolvers by IP address, from a single server. So it knows nothing about what someone in Tokyo sees. The tools that paint a world map full of flags query those exact same addresses: they aren't measuring geography, they're measuring the state of a handful of very large caches. We show it for what it is, and we add the piece they leave out — the value your zone's own name servers publish, the only reference that tells you whether an answer is the current one or the old one.
Watching it, instead of refreshing it
On migration day you'll refresh this page every five minutes. Fair enough — and it's the one thing a one-shot checker can't do for you: speak up on its own. DomainVigil reads your records around the clock and writes to you when they change, including when they change without you, because a contractor edited the zone or a transfer put the old name servers back. On migration day the checker is enough. The other 364, monitoring is what counts.
The clocks that decide
Forty-eight hours? Four numbers are enough.
None of these clocks is negotiable once the migration is under way. Three are set beforehand; only one is yours on the day.
172,800s
A .com delegation
The one layer that justifies “up to 48 hours”, and it covers a single thing: a change of name servers. The registry sets it, not you.
3,600s
The same delegation, in .fr
Forty-eight times shorter, for the exact same change. The TLD you picked governs the wait far more than your host does.
300s
To publish the day before
The TTL to put on the record 24 hours before the switch. Afterward is too late: caches are already holding the old value under the old TTL.
8
Resolvers queried
On every check, plus your zone's own name servers — the only authoritative answer, and what the table compares against.
The first two are what the registries publish on the delegation. The third is what you set in your own zone. The fourth is what this checker does.
Received wisdom
What people say about propagation, and what actually happens
You hear the four sentences on the left every day. Not one of them is true, and each one costs a night of waiting.
What people believe
What actually happens
“A DNS change takes 48 hours to propagate.”
The 48 hours only ever applied to a .com delegation. An A record moves at the TTL your zone publishes, often one hour.
“You have to wait for the resolvers to agree with each other.”
No resolver consults another one. Each holds its own copy until THAT copy expires, and its clock started the day it asked.
“Flushing my cache speeds up propagation.”
Flushing a cache changes the machine you flush it on, and nothing else. Public resolvers keep theirs, and theirs is what your visitors get.
“My browser still shows the old site, so the change hasn't gone through.”
Three caches stack up behind the resolver: the operating system's, the browser's, and often a content delivery network in front of the site.
Reading the table
Each row is one resolver. Its dot says how that resolver's answer compares with the value your zone publishes.
- Same as the zone
- This resolver is serving the value your name servers publish. For everyone behind it, the change is done.
- Differs from the zone
- This resolver is serving something else. Either its cache hasn't expired, or a content delivery network is handing it an address meant for its region. The TTL column settles it: a number that drops from one check to the next is a cache on its way out.
- No record of this type
- The name exists but carries nothing of this type, or the resolver cached the absence. Right after you create a record, that's the normal state for as long as the zone's negative cache lasts.
- No answer
- The resolver sent nothing back within four seconds. These services are shared and they rate-limit; silence tells you nothing about your domain.
- TTL
- How long before this resolver asks again. DNS only exposes it for A and AAAA records; for other types the column stays empty, and we'd rather leave it empty than invent a number.
- What the zone says
- The block at the top. That value comes straight from one of the domain's name servers, with no cache in between. It's the authoritative one — and without it, eight matching answers prove nothing.
Mistakes that look like a propagation problem
Most of the time, when “DNS won't propagate”, there's nothing to propagate: the record was never published where you're looking for it.
The change was made at the registrar, but the zone is served somewhere else
What causes it: The domain is registered with one provider and its name servers point at another. The registrar's panel then shows you a zone nobody reads.
What fixes it: Query the NS type above. The servers that come back are the ones that count — that's where the record has to be edited, not at the registrar.
Waiting 48 hours for an IP address change
What causes it: The 48-hour figure belongs to changing the name servers of a .com, not to an A record. Two different TTLs, set by two different parties.
What fixes it: A record moves at the TTL your zone publishes, often one hour. A delegation moves at the TTL the registry sets: 172,800 seconds for a .com, 3,600 for a .fr.
Every resolver is up to date and the browser still shows the old site
What causes it: Three caches sit behind the resolver: the operating system's, the browser's, and often a content delivery network in front of the site.
What fixes it: Flush the system cache (“ipconfig /flushdns” on Windows, “sudo dscacheutil -flushcache” on macOS), then the browser's. Chrome has a button for it on “chrome://net-internals/#dns”.
The TXT record was created and no resolver sees it
What causes it: That resolver had already answered “this name carries nothing” before the record existed, and it remembers the absence. That's negative caching, set by the last field of the zone's SOA record (RFC 2308).
What fixes it: Wait that field out. It's 600 seconds on AFNIC's .fr zone and 1,800 on plenty of hosted zones. Nothing speeds it up from outside.
Two resolvers give two different addresses, and it never changes
What causes it: That isn't propagation. The domain is served by a content delivery network or a geographic split, which hands each caller an address close to them.
What fixes it: Compare against the zone's own value. If that varies from one name server to the next too, the setup is deliberate and there's nothing to fix.
The layers of a propagation, and who controls each one
“It can take up to 48 hours” is the line every host gives you. It's true of exactly one of these layers. Here are the six, with what causes each one and who holds the clock.
| Layer | Duration | Who sets it, and what speeds it up |
|---|---|---|
| Record TTL | the published value, 60 to 86,400 seconds | You, in your zone. Drop it to 300 seconds 24 hours BEFORE a migration. Once the change is out it's too late: caches are holding the old value under the old TTL. |
| Negative cache | the last SOA field, often 600 to 3,600 seconds | Your zone. It applies to a CREATION: the resolver remembered that the name carried nothing. Measured September 12: 600 s on AFNIC's .fr zone, 1,800 s on a zone hosted at Cloudflare. |
| NS delegation | 172,800 seconds for a .com, 3,600 for a .fr | The registry for the TLD, not you. This is the one layer that justifies “up to 48 hours”, and it only covers a name server change. |
| ISP resolver | the TTL, sometimes longer | Your ISP. Some stretch an answer's life past the TTL to save traffic, and those are the networks where a change looks like it never goes through. |
| Operating system cache | until reboot | Your machine. “ipconfig /flushdns” on Windows, “sudo dscacheutil -flushcache” on macOS, “resolvectl flush-caches” on Linux. |
| Browser cache | independent of the system | Chrome and Firefox keep their own table. In Chrome, “chrome://net-internals/#dns” clears it without closing the browser. |
The move that changes everything happens BEFORE the migration, not after: drop the record's TTL to 300 seconds the day before, put it back the day after. Almost nobody does it, and that's why everybody waits 48 hours.
Common questions
How long does DNS propagation actually take?
The TTL your zone publishes for that record, and not a second longer — that goes for an IP address, an MX or a TXT. One hour is the most common value. The 48 hours you keep hearing about covers one case only: changing the name servers of a .com, because the registry publishes that delegation with a TTL of 172,800 seconds. The same change on a .fr takes an hour.
Why can I see the new site when my client still gets the old one?
Your two machines aren't asking the same resolver. Yours has already picked up the new value; your client's still holds the old one until its cache expires. The table above shows it resolver by resolver. If the gap doesn't move across several checks, it isn't a cache — it's a geographic answer, or a record edited in the wrong zone.
Can I speed up DNS propagation?
Not from the outside. A cache belongs to whoever runs it, and no tool can make it forget. Two things are in your hands: lower the record's TTL before the change, and flush your own machines after it. Google and Cloudflare each publish a page that purges one entry from their public cache, which fixes their case and nobody else's.
Why is the time-to-live column empty for MX and TXT records?
Because the DNS library we use only returns it for A and AAAA records. An empty column beats an invented number. The TTL for the type you're looking at sits next to the record in your zone editor.
Every resolver is up to date and I still get the old site. Why?
DNS has done its job; the problem is downstream. Start with your browser cache and your system cache. Then the content delivery network in front of the site, if there is one — Cloudflare, for instance, keeps its own copy of your pages and you have to purge that separately. Then the server itself, which can serve two different sites depending on the host name it gets.
Are eight resolvers enough to be sure?
To know whether a change has gone through, yes: these eight services handle a considerable share of the world's queries, and they don't share a cache. To know what one particular visitor in one particular country sees, no — and no public tool knows that either, including the ones with a map.
The timeline
A hosting migration, hour by hour: what you see, what's actually going on
The script never changes, and the panic always lands in the same place. Here are the seven moments of an ordinary switch, each one next to what's really happening inside the caches.
D − 7
Everyone gets told except the caches
What you see
The date is set, the new host confirms, the team blocks out Tuesday morning.
What's happening
The A record is still publishing a TTL of 14,400 seconds. Until somebody changes that, it's the value every resolver carries away with its next copy — and it's still worth four hours on switch day.
D − 1, 9 am
The one move that shortens the wait
What you see
The TTL goes from 14,400 to 300 seconds in the zone. “There. Now it'll be quick.”
What's happening
Only the resolvers that ask again read the new TTL. The ones that copied yesterday keep the old one, in full. So the drop has to happen at least one old TTL before the switch — four hours here, not one. The day before is plenty. The morning of does nothing.
D, 10:00
The switch
What you see
The new address goes live. On the machine that just typed it in, the site already answers from the new server.
What's happening
No resolver has been told a thing. The protocol has no way to tell them: each one finds out when its own copy expires, on its own schedule (RFC 1035, § 3.2.1).
D, 10:05
The first phone call
What you see
“I still get the old site.” Two minutes later, a second call, with a different screen.
What's happening
The first caller's resolver copied at 10:02, so its copy holds until 10:07. The second caller's copied at 9:58, under the old four-hour TTL. Both of them are right, and nothing settles it but time.
D, 10:30
The test that proves nothing
What you see
A colleague flushes their cache, reloads, gets the new site. Everyone decides it has gone through.
What's happening
That measured one machine, not a network. The only reference is what one of the zone's own name servers hands back, queried with no cache in between — the block at the top of this page.
D, 11:15
The site loads, the padlock doesn't
What you see
The new server answers fine, but the browser throws a certificate warning.
What's happening
This isn't DNS anymore. You request a certificate once the name points at the new server: the authority checks either a file that server hands back or a TXT record in the zone. Before the switch, neither check could pass.
D + 2
Put the TTL back
What you see
Nobody has complained since yesterday. The migration is closed.
What's happening
Leaving 300 seconds in place for good means your name servers field forty-eight times the queries. Put it back to an hour once the switch holds — and write down the date, because the next migration starts by lowering it again.
The durations here are those of an ordinary zone; yours sit next to each record in your DNS panel. The one step outside your hands is the delegation, held by the registry for your TLD.
At 3 am
The site stopped answering after the switch: what to check, and in what order
Six situations, and the one place to look for each. The table at the top answers in three seconds: always read the “what the zone says” line against the resolver lines.
IfThe top block shows no value at all for the zone
CheckThe domain's NS records, then whoever hosts the zone.
Because If the name servers stop answering, nothing can resolve the name once the caches run out. It's the only failure on this list that gets worse on its own.
IfThe zone answers the new value, the resolvers the old one
CheckNothing. There's nothing to fix here, only time to wait.
Because The change is published and correct. The longest anyone waits is the TTL that was published before the change, not the one in place now.
IfThe zone answers the old value
CheckWhere the zone is actually served: the NS records, and the panel that runs those servers.
Because The change went into a zone nobody reads anymore — almost always the registrar's, while the name servers point somewhere else.
IfSome resolvers answer “no such record”, others the right value
CheckThe zone's negative cache, set by the last field of the SOA record.
Because Those resolvers asked before the record existed and memorized the absence (RFC 2308). Nothing speeds that up from outside: that copy expires like any other.
IfThe bare domain works and “www” doesn't, or the other way around
CheckThe zone, record by record: these are two separate names.
Because “www” is a record in its own right. Nothing in DNS creates it from the domain, and plenty of migrations copy over only one of the two.
IfThe name resolves to the right address and the server still serves the old site
CheckIn this order: the browser cache, the system cache, the content delivery network in front of the site, then the server config.
Because DNS has done its job. Three caches stack up behind it, and one server can serve two sites depending on the host name it gets.
Worth bookmarking
DNS response codes: NOERROR, NXDOMAIN, SERVFAIL, REFUSED
Every DNS answer carries a four-bit code. It shows up on dig's “status” line, and on its own it tells you which side to look at.
| Code | What it says | What to look at |
|---|---|---|
| NOERROR (0) | The query succeeded. | Watch the trap: a NOERROR can come back with no answer at all. The code alone isn't enough — count the records returned. |
| NOERROR, zero answers | The name exists, but it does not carry the type you asked for. | Not a separate code: it's the state RFC 2308 calls NODATA. After a creation, it's what your zone returns until the record goes live — and what resolvers keep in their negative cache. |
| NXDOMAIN (3) | The name does not exist. | And nothing below it either: since RFC 8020, an NXDOMAIN covers the whole subtree. On a name you just created, that's the zone's negative cache, not an error. |
| SERVFAIL (2) | The resolver could not produce an answer. | First suspect: DNSSEC validation failing — an expired signature, or a DS that no longer matches the published key (RFC 4035). The giveaway is that the name fails on validating resolvers and works on the ones that don't validate. |
| REFUSED (5) | The server refuses to answer, as a matter of policy. | Almost always this: you're querying a server that isn't authoritative for the zone and won't do recursion. Check which server the query went to before you blame the zone. |
| NOTAUTH (9) | The server queried is not authoritative for this zone. | A leftover from the old delegation, or a secondary that never got the transfer. Compare the NS list the registry publishes with the one the zone publishes. |
| FORMERR (1) | The query was not understood. | Rarely your zone: more often a middlebox truncating EDNS responses. It turns up on long answers, DNSSEC first among them. |
Codes are defined in RFC 1035, § 4.1.1, and tracked in IANA's “DNS RCODEs” registry. Since RFC 8914 a resolver can attach an extended DNS error that gives the reason — “DNSSEC Bogus” behind a SERVFAIL, for instance. dig prints it as EDE when it's there.
The move that changes everything happens before the migration, not after.
The move
Changing hosts with no downtime: a calendar in three parts
Nearly everything you can do, you do before the switch. Once the change is published there's only waiting left — and not believing in the moves that do nothing.
Before — the only window where you act
- Write down the current TTL of every record about to change, so you can put it back.
- Drop it to 300 seconds at least one old TTL before the switch. That one move decides everything else.
- Check where the zone is actually served by querying its NS records. That's where edits count, not necessarily at the registrar.
- If the migration creates names that didn't exist, lower the last field of the SOA too: it sets the negative cache.
- List the records that must NOT move — MX, authentication TXT, CAA — and check they exist identically in the new zone before you delegate.
During — check the zone, not your own screen
- Publish, then check what one of the zone's name servers hands back. While that's wrong, looking at resolvers is pointless.
- Keep the old server running and healthy for at least one old TTL. Visitors will still land on it, and an error page does more damage than a slightly stale one.
- For a name server change, plan on the delegation TTL the registry holds, not yours: 172,800 seconds for a .com, 3,600 for a .fr.
- Request the certificate once the name points at the new server, never before: the check runs through that server or through the zone.
After — close it out properly
- Put the TTL back to its original value once the switch holds, or your name servers take forty-eight times the traffic.
- Check the records that weren't supposed to move. A zone rebuilt by hand quietly loses whatever nobody mentioned: SPF, DKIM, DMARC, CAA, ownership verifications.
- Shut the old server down last, and keep its backup. Rolling back means republishing the old address — which only works if something is still there.
What does nothing
- Flushing your own machine's cache to speed things up for everyone else: it changes what you see, and nothing more.
- Pointing your machine at a public resolver to “check”: you're measuring that resolver, and you've lost sight of your own ISP's.
- Calling your host to have them “force propagation”: no operator can flush someone else's cache.
- Deleting the record and creating it again: it flushes nothing, and it adds a negative cache to wait out.
- Waiting 48 hours on principle: that number only applies to a name server change, and not in every TLD.
The vocabulary
Eight words you read everywhere and never see defined
These are the terms in the table above, in what dig prints back, and in your host's control panel.
TTL- Time to live, in seconds. A ceiling each cache counts from ITS OWN query, never from your change.
SOA- A zone's header record. Its last field sets how long a negative answer stays cached.
negative cache- The memory of an absence: the resolver recorded that the name carried nothing. It's what you wait out after creating a record (RFC 2308).
resolver- The server that answers your machine. It asks the zone once, then serves that copy to everyone behind it.
zone- Every record a domain has, as its name servers publish them.
delegation- The name servers the TLD registry names as authoritative for the domain.
authoritative- An answer that came from a server of the zone itself, with no cache in between. It's what the table compares against.
NXDOMAIN- The name doesn't exist — and nothing below it does either, since RFC 8020.
Twenty checks, no sign-up
- Build your SPF record
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?