Why Your Site Doesn't Work After a DNS Change and How Long

In short. Nothing actually "propagates". On your own authoritative server the record changes instantly. What you wait for is other people's resolvers to expire their cached copy of the old answer. The wait is set by the TTL that was on the record at the moment you edited it — not by the "24–72 hours" in your registrar's email. Drop the TTL to 300 seconds in advance and you wait five minutes.

Below, in order: why the site still loads from the old server for you but already from the new one for a colleague; where the "two days" figure came from; how to see, with one command, how much life is left in a stale answer inside someone else's cache; and what genuinely speeds things up versus what is a myth that costs you downtime.

Why Your Site Doesn't Work After a DNS Change

The symptom is always the same. You update the A record at your registrar or in your DNS hosting panel, open the site — and see the old server. Sometimes only part of your users see the stale version, sometimes only you, while everyone else is fine.

The reason is not that the change "hasn't arrived yet". It has already been applied: your authoritative DNS server holds the new value, and anyone who asks that server directly gets the new address right now. The problem is the middlemen.

A browser almost never asks your authoritative server. It asks a resolver — the DNS server of an ISP, a corporate network, or a public one such as 8.8.8.8. Minutes or hours ago that resolver already asked about your domain, received the old answer, and put it in its cache. Until that cache expires, the resolver keeps serving the old value and never contacts you at all.

The word "propagation" is misleading. There is no distribution of changes across the internet — not a single server is notified that you edited an A record. The opposite happens: old copies simply go stale on a timer, each at its own moment. It is more accurate to say "caches expire" than "changes spread".

Why It Works for You but Not for Your Colleague

You and your colleague almost certainly go through different resolvers: different ISPs, different corporate networks, different router settings. Each resolver fetched your record at its own moment, and its timer will expire at its own moment.

Even if you both point at 1.1.1.1 or 8.8.8.8, that is not one server. Public resolvers run on anycast: the same IP address is announced from dozens of data centres worldwide, and your query lands on the nearest one. Your request is handled by a node in one city, your colleague's by a node in another, and their caches are independent.

This is easy to observe: two identical queries to 1.1.1.1 a few seconds apart can return a different remaining TTL, because they hit different nodes.

$ dig +nocmd +noall +answer @1.1.1.1 enterno.io A
enterno.io.		3600	IN	A	81.163.20.249

$ sleep 3; dig +nocmd +noall +answer @1.1.1.1 enterno.io A
enterno.io.		1771	IN	A	81.163.20.249

The first answer came back with the full TTL of 3600 — that node fetched the record fresh. The second came back with 1771 seconds remaining — a different node had been holding it for nearly half an hour. Same resolver address, two completely different caching histories.

Cloudflare and Quad9 will tell you which node answered:

$ dig +short CH TXT id.server @1.1.1.1
"ams15"

$ dig +short CH TXT id.server @9.9.9.9
"res721.qams5"

Google's 8.8.8.8 does not answer that query, but the principle holds. The practical takeaway: "I checked via 8.8.8.8 and it's updated" is not evidence that it has updated for everyone.

How Long DNS Changes Take to Update

The upper bound is calculated like this: the TTL that was on the record when a resolver cached it, plus the time it took your edit to reach all of your authoritative servers. The second term is usually seconds or minutes; the first is what decides everything.

The worst case is a resolver that fetched the record one second before your edit. It will keep serving the old value for exactly as long as the TTL says. If that was 86400, expect a full day. If it was 300, five minutes.

"24–72 hours" is neither a standard nor a property of DNS. It is a cautious phrase from templated registrar emails, covering high default TTLs, the publication delay in the TLD zone when nameservers change, and corporate caches with unusual settings. As a worst-case ceiling it is fine. As a forecast for your specific situation it is useless.

Here is what actually determines the wait for each record type.

Record	What sets the wait	Typical default TTL	Cost of a mistake
A / AAAA	The record's own TTL	1–4 hours	Part of the traffic keeps hitting the old server
CNAME	TTL of the alias and TTL of the target — they expire independently	1–4 hours	You wait twice
MX	Record TTL; senders also retry for hours	4–24 hours	Mail delivered to a decommissioned server
TXT (SPF, DKIM, DMARC)	Record TTL, cached on the recipient's side	1–24 hours	Mail marked as spam or rejected outright
NS	TTL of the delegation in the TLD zone — not yours to control	1–2 days	SERVFAIL: the whole domain goes dark
SOA / negative answers	The minimum field in the SOA record	15 minutes – 3 hours	NXDOMAIN sticks after you create the record

The one row where you are not in charge is NS. The delegation TTL is set by the top-level zone, not by you. That is why nameserver changes really can be slow, and they get their own section below.

How DNS Works: From Browser to Authoritative Server

To understand where the stale value gets stuck, you need to see the whole path of a query. A full walkthrough of the system lives in what DNS is and how it works; here is only what affects timing.

1. Browser cache — its own short-lived cache, usually minutes.
2. Operating system cache — the resolver service on your machine.
3. Recursive resolver — your ISP's DNS, a corporate server, or a public one (8.8.8.8, 1.1.1.1, 9.9.9.9). The main source of delay.
4. Root servers — 13 addressed groups that point to whoever runs .com, .org, .io.
5. TLD zone servers — hold the delegation: which nameservers serve your domain.
6. Authoritative servers — where the real records live. This is where your edit appears immediately.

Every level may cache. That is exactly why a change looks "gradual": it is not travelling across the network, different caches simply free up at different times.

Telling a Cached Answer From an Authoritative One

An authoritative server sets the aa flag (authoritative answer) in its reply. A resolver does not. This is the most reliable "did it really change" test:

$ dig +norecurse @dns1.yandex.net enterno.io A
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

The aa flag is present, so the server is answering as the owner of the zone rather than repeating someone else's cache. If the new value is here but resolvers still show the old one, your side of the job is done and all that remains is waiting.

TTL: What It Is and How It Sets the Wait

TTL (time to live) is the number of seconds a resolver is allowed to keep an answer. It travels with the record in every reply. Until the counter reaches zero, the resolver will not contact you.

example.com.  3600  IN  A  203.0.113.10
;             ^^^^
;             TTL = 3600 seconds = 1 hour

A field-by-field reference is in the guide to TTL in DNS records. Below is a working cheat sheet for choosing a value.

TTL	Duration	When to use it	The downside
60	1 minute	Live incident, manual failover	Many resolvers clamp it up to their own floor anyway
300	5 minutes	Migration window, load balancing	More queries hitting your authoritative servers
3600	1 hour	Sensible default for working records	An hour of downtime after an unplanned edit
14400	4 hours	Stable records nobody touches	Half a day to roll back
86400	24 hours	Records that change once a year	A full day of downtime if you get it wrong
604800	7 days	Practically never needed	A week with no way to roll back

TTL is not "how fast it updates", it is "how long you will be unable to roll back". A high TTL does not punish you for making a change, it punishes you for making a wrong one. Choose it based on how much downtime you can tolerate if the new record turns out to be incorrect.

Reading the Time Left Before a Cache Expires

The TTL in a resolver's answer is not the value you configured in your zone — it is the remainder, counting down. Query the domain twice with a pause: if the number drops, you are looking into a cache and seeing exactly how much longer it will serve the old data.

# Remaining cache lifetime at a specific resolver
dig +nocmd +noall +answer @8.8.8.8 example.com A

# Ten seconds later the number should be 10 lower
sleep 10; dig +nocmd +noall +answer @8.8.8.8 example.com A

If the second answer shows the full TTL from your zone again, the cache has just expired and been refilled — meaning that resolver is now serving current data.

Peeking Into a Cache Without Filling It

A normal query to a resolver that does not hold the record will make it go and fetch one, then cache it. Sometimes that gets in the way: you want to know what it holds right now without changing anything. That is what +norecurse is for:

# Serve what you have cached, but do not go and fetch anything
dig +norecurse +nocmd +noall +answer @8.8.8.8 example.com A

An empty answer means this node has nothing cached — so the next ordinary user query will trigger a fresh lookup against your authoritative server.

Why Caches Outlive the TTL: Five Layers

Your ISP's resolver is not the only thing holding the answer. Even after it refreshes, a stale value can survive closer to the user.

Layer	Who controls it	How to clear it	Affects visitors
Browser cache	The user	Restarting the browser, its network internals page	Only that one person
OS cache	The user	A flush command	Only that one person
Router, corporate proxy, VPN	The network admin	Rebooting the device	The whole office network
Recursive resolver	The ISP or public service	TTL expiry only	Every client of that resolver
Delegation in the TLD zone	The domain registry	Zone TTL expiry only	Everyone

The "TTL expiry only" rows are the important ones. The next sections explain why there is no way around them.

Negative Caching: When NXDOMAIN Sticks

A separate class of problem: you created a record but it "won't appear", even though the TTL is low. This happens when somebody queried the name before the record existed. The resolver got an NXDOMAIN and cached the absence itself. How long it keeps that is set not by the record's TTL — there was no record — but by the minimum field of the zone's SOA record, the last number in it.

$ dig +nocmd +noall +authority nonexistent-xyz123.enterno.io A @8.8.8.8
enterno.io.  900  IN  SOA  dns1.yandex.net. dns-hosting.yandex.ru. 36 900 90 86400 900
;                                                                  ^^  ^^^ ^^ ^^^^^ ^^^
;                                                          serial refresh retry expire minimum

Here minimum is 900 seconds, so "this name does not exist" will be cached for up to fifteen minutes. The rule is defined in RFC 2308: the negative cache lifetime is the lesser of minimum and the SOA record's own TTL.

The practical consequence: create the record before anyone learns about it. Share a link to a new subdomain before adding its A record and the first few clicks will poison caches with a negative answer for a quarter of an hour — even though the record is now in place.

DNS Record Types and How They Behave on Update

Syntax and purpose for each type are covered in the DNS records reference. Here is only what matters during a migration.

A and AAAA

The most common case: changing hosting. The rule is simple — both records change together. A forgotten AAAA record produces the classic "half my users see the old site" symptom: anyone with working IPv6 goes to the old address, everyone else to the new one.

Check both address families explicitly:

dig +short A    example.com @8.8.8.8
dig +short AAAA example.com @8.8.8.8

# And the same for www — it is a separate record
dig +short A    www.example.com @8.8.8.8

CNAME

A CNAME is an alias: it says "go ask this other name instead". A resolver caches two things independently — the alias itself and the resolution of its target. So an update behind a CNAME can drag on longer than the sum of the two waits: the target's cache has to expire, then the alias's, and the order is unpredictable.

The second consequence: a CNAME cannot sit at the zone apex (example.com with no subdomain), because SOA and NS records already live there. Providers work around this with non-standard types such as ALIAS or CNAME flattening, and their behaviour — including TTL handling — differs between vendors.

MX and Email

A mistake in an MX record costs more than a mistake in an A record: you cannot "reload" a message that was never accepted. Email is more forgiving than the web in one respect — a sending server that fails will retry for hours rather than give up immediately. That buys you slack, but it does not remove the need to prepare.

"Set a high TTL on MX records" is harmful advice if you intend to change them. A high TTL does not protect mail; it merely lengthens the window in which some senders still deliver to the old server, and it makes rollback impossible. High TTLs suit records you never touch — before a migration you lower them like any other.

TXT: SPF, DKIM, DMARC

Email authentication records are cached on the recipient's side, and you have no influence over that cache whatsoever. While a receiving server still holds your old SPF, mail from the new address counts as unauthorised.

Hence the transition rule: add the new value alongside the old one, let the caches turn over, and only then remove the old. For SPF that means temporarily listing both sending sources; for DKIM, keeping two selectors live at once. To see what the outside world actually reads, use the email records check and MX lookup.

NS: The Longest Case

Changing nameservers is different because the answer is cached not only by resolvers but at the TLD zone level. The delegation TTL is set by the domain registry — typically a day or two — and you cannot lower it.

Add to that the delay between registrar and registry: an NS change in your registrar's panel is not published in the zone instantly. Then the TLD zone itself has to reach its own servers.

Configure the zone fully on the new nameservers before changing the delegation. If a resolver reaches a server that does not consider itself authoritative for the domain, you get SERVFAIL — and that is not "the old site", that is the entire domain going dark, cached.

If the domain has DNSSEC enabled the order is stricter still: remove the signing and wait for caches to expire before switching nameservers, otherwise validating resolvers will discard answers from the new servers as forged. To see who currently serves a domain and which nameservers are on file, use a WHOIS lookup.

How to Check Whether DNS Has Updated

"I opened the site in a browser" proves nothing: you are seeing exactly one resolver with three layers of cache on top. You need several vantage points.

Using enterno.io

The fastest route is the DNS propagation check: it queries your domain from a couple of dozen independent resolvers in different networks and countries and shows which value each one returns. A disagreement in that list is the unfinished update; once every row matches, there is nothing left to wait for.

To review the whole record set for a domain with its TTLs rather than a single record, use DNS Lookup. A wider overview of approaches and tooling is in the article on ways to check DNS propagation.

Using dig

Comparing several public resolvers in one line:

for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  printf "%-16s %s\n" "$ns" "$(dig +short @$ns example.com A | tr '\n' ' ')"
done

And the same across the domain's authoritative servers, which are required to agree with each other:

# Find the authoritative servers
dig +short NS example.com @8.8.8.8

# Ask each one directly, no recursion
for ns in $(dig +short NS example.com @8.8.8.8); do
  printf "%-24s %s\n" "$ns" "$(dig +short +norecurse @$ns example.com A)"
done

A disagreement between authoritative servers is no longer a caching wait — it is a zone that is out of sync: one copy accepted the edit while another still runs an older serial. Waiting will not fix it; your DNS host will.

On Windows

nslookup -type=a example.com 8.8.8.8
nslookup -type=a example.com 1.1.1.1

REM Show the TTL in the answer
nslookup -type=a -debug example.com 8.8.8.8

REM Inspect what Windows itself has cached
ipconfig /displaydns | findstr /i example.com

Without Installing Anything — Over HTTPS

If you have neither dig nor nslookup to hand, public resolvers answer over HTTP. This is also convenient for scripts and monitoring:

# Cloudflare
curl -s -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=example.com&type=A'

# Google — the reply shows both the TTL and which server answered
curl -s 'https://dns.google/resolve?name=example.com&type=A'

The TTL field shows the same remaining cache lifetime that dig would. A full TTL means a fresh answer; a shrinking one means a cache.

How to Speed Up a DNS Update

The honest answer: once you have made the change, there is almost nothing you can do to accelerate it. Everything that genuinely works is done beforehand.

Lower the TTL Before the Change — the Only Reliable Technique

The sequence:

1. Longer ago than the current TTL — usually a day or two — set the TTL to 300 seconds. Do not touch the record's value yet.
2. Wait for the old TTL to expire everywhere. This is the step people skip: if the TTL was 86400, changing the record an hour after lowering it achieves nothing, because resolvers still hold the old copy under the old lifetime.
3. Make the change. The disagreement window is now five minutes.
4. Confirm everything works, then restore the TTL to its working value.

; Step 1 — a day before migration: change ONLY the TTL
example.com.      300  IN  A  203.0.113.10
www.example.com.  300  IN  A  203.0.113.10

; Step 3 — migration window: change the address
example.com.      300  IN  A  198.51.100.25
www.example.com.  300  IN  A  198.51.100.25

; Step 4 — a few days later: restore the TTL
example.com.      3600 IN  A  198.51.100.25

Flush Local Caches

This helps you and your colleagues confirm things look right. It does nothing for your visitors.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

# Linux, older systems (systemd before 239)
sudo systemd-resolve --flush-caches

Browsers deserve a separate note: each keeps its own short cache and, if DNS-over-HTTPS is enabled, its own resolver that does not match the system one. The simplest check is a private window after a full browser restart.

What Does NOT Speed It Up

• Flushing your own machine's cache. It changes the picture for you alone. A user on the other side of the country still sees the old address.
• Re-saving the record in the panel. It does not clear anyone else's cache. It does bump the zone serial and can trigger needless resynchronisation.
• Lowering the TTL at the moment of the edit. The new TTL only applies to whoever queries after the old one expires. Too late is too late: you sit out the full original interval.
• "Purge cache" forms offered by public resolvers. Some services do have them, but they affect one node out of many and do nothing for ISP resolvers.
• Restarting the site or the server. Unrelated to DNS.

You cannot make someone else's resolver forget an answer. No mechanism in DNS lets you recall a record that has already been handed out early. All control over the wait happens before the change, never after.

About Cloudflare and Other Proxy Services

You will often read that "changes take effect instantly with Cloudflare". The phrasing is imprecise and leads people astray. What takes effect instantly is a change of origin address in the proxy settings: the public A record still points at the service's own anycast address and does not change at all — there is nothing to change and nothing to cache.

The moment you touch something visible from outside, though — turning the proxy off, changing nameservers, or changing the public address itself — ordinary TTL rules apply. A proxy service moves the caching boundary; it does not abolish it.

DNS and Email: Not Losing Mail During an MX Change

While caches disagree, some senders deliver to the old server and some to the new one. Losses come not from the disagreement itself but from decommissioning the old server too early.

• Do not shut down the old mail server until you have confirmed traffic to it has stopped. As a baseline, allow at least the previous TTL plus room for sender retries.
• Set up forwarding from the old server to the new one for the whole transition, so even a late message still arrives.
• Lower the TTL on MX records in advance, along with everything else.
• Do not delete the old SPF entry and old DKIM selectors at the moment of the switch: keep old and new side by side until recipient caches turn over.
• Send test messages from several external providers and read the headers — they show which server accepted the mail.

Troubleshooting: Symptom, Cause, Check, Fix

Symptom	Likely cause	How to check	What to do
Old site for me, new for everyone else	Local OS or browser cache	dig +short @1.1.1.1 versus what the browser loads	Flush the OS cache, retest in a private window
Old site for half the users	AAAA record or www forgotten	dig +short AAAA and a separate query for www	Update every record in the family
A day has passed, nothing changed	The edit never reached the authoritative servers	Query each NS with +norecurse, look for aa	Check the zone with your DNS host instead of waiting
A different answer on every query	Round robin, different anycast nodes, or an out-of-sync zone	Poll all authoritative servers in turn	If the authoritative servers disagree, contact the host
SERVFAIL after an NS change	New servers do not serve the zone, or DNSSEC is broken	Direct query to the new NS, check the DS record	Configure the zone before delegating; remove DNSSEC first
A new record "won't appear"	Negative caching of NXDOMAIN	The minimum field in SOA	Wait out the SOA interval; do not recreate the record
Mail still goes to the old server	MX cached at the senders	MX lookup from several points	Keep the old server and forwarding switched on
Mail landed in spam after the move	Old SPF or DKIM in the recipient's cache	Email records check	Keep old and new values live simultaneously

DNS Migration Checklist

Several days ahead.

1. Write down every record on the domain and its current TTL, via DNS Lookup.
2. Lower the TTL to 300 seconds on everything you plan to change, including www, AAAA and MX.
3. Confirm the new server is genuinely ready: the site loads by IP, the certificate is issued, mail is accepted.
4. If you are changing nameservers, build and populate the zone on them in advance; with DNSSEC, remove the signing first.

Right before the switch.

1. Wait for the old TTL to expire — not to be confused with the moment you lowered it.
2. Verify that resolvers are already returning the record with the new short TTL.
3. Schedule the window for a low-traffic period and tell the people it affects.

After the switch.

1. Check DNS propagation across resolvers in different countries.
2. Confirm that all authoritative servers return the same answer.
3. Watch the logs on both servers: while traffic still reaches the old one, it stays up.
4. Point uptime monitoring at the new address so you hear about a problem before your users do.
5. After several quiet days on the old server, restore the TTL to its working value.
6. A week later, decommission the old server.

Frequently Asked Questions

How long does a DNS change take to update?

As long as the TTL on the record at the moment you edited it, plus minutes for publication on your authoritative servers. With a TTL of 300 that is five minutes; with 86400, up to a day. Nameserver changes can take longer because the TLD zone sets that interval, not you.

Where does "24–72 hours" come from?

It is boilerplate from registrars covering the worst conceivable case. It is not a standard: DNS has no such concept, and every interval in it is defined by TTL values and the minimum field of the SOA record.

Why does it work for me but not for my client?

You use different resolvers with independent caches, and their timers expire at different moments. Even a single public address like 1.1.1.1 is many anycast nodes, each with its own cache. Check across many resolvers at once rather than in a browser.

Can I force an ISP resolver to drop its cache?

No. DNS has no mechanism for recalling a record early. Flushing the cache on your own machine changes the picture only for you. The wait can be controlled in advance, through TTL, and in no other way.

Three days have passed and the site is still the old one. What now?

At that point it is a configuration error, not a cache. Query each authoritative server directly with +norecurse: if the old value is there, the edit was never applied; if the servers disagree, the zone is out of sync. Both are fixed by your DNS host, not by waiting.

Does changing DNS hurt search rankings?

Not in itself — crawlers use the same resolvers and TTLs as everyone else. Downtime is what hurts: if some crawlers hit a dead server during the switch, pages can drop out of the index temporarily. That is precisely why the old server stays up until the end.

Should I restore the TTL after a migration?

Preferably. A low TTL means a constant stream of queries to your authoritative servers and slightly slower first connections for users. Restore your working value after a few days, once you are confident no rollback is needed.

Key Points

• The change applies instantly — what you wait for is other people's caches expiring, not "propagation".
• The wait is set by the TTL that was on the record at the moment you edited it.
• "24–72 hours" is a registrar's worst-case ceiling, not a property of DNS.
• The only reliable way to go faster is lowering the TTL in advance and waiting out the old one.
• After the edit, nothing you do can force a third-party resolver to refresh.
• Change A and AAAA together and do not forget www, or half your users will see the old site.
• Nameserver changes are the slowest case: the delegation TTL belongs to the TLD zone.
• If a new record "won't appear", look for a negative cache — the interval is in the SOA minimum field.
• Keep the old server and the old SPF entry live until traffic to them stops.
• A browser check proves nothing: look at the spread across resolvers and the aa flag on authoritative servers.