Old answer everywhere
Check which nameservers are authoritative and confirm you edited the zone they actually serve. A common migration mistake is changing records at a registrar while DNS is hosted somewhere else.
DNS Changed but Website Still Points to the Old IP
You changed DNS, but visitors still reach the old server. The useful question is not “has DNS propagated yet?”—it is which layer is still returning or routing to the old address.
Quick diagnosis
If the authoritative DNS already returns the new IP but some users still reach the old server, a recursive resolver can still be serving an earlier cached answer until its previous TTL expires. If the authoritative DNS itself still returns the old value, waiting for propagation will not fix the problem: the active DNS zone or delegation is still wrong.
Resolvers disagree
This usually points to cache state. Independent recursive resolvers can refresh at different times because they did not all cache the record at the same moment.
DNS is new, site is old
Look beyond DNS. A CDN, reverse proxy, origin mapping, HTTP redirect or application cache can still route requests to old infrastructure even when the A or AAAA answer is correct.
Only some networks fail
Compare IPv4 and IPv6, the local resolver, VPN or secure-DNS provider. One path may still use an old A/AAAA answer while another path has already refreshed.
Step 1: confirm the DNS answer you expect
Start with the DNS Checker. Check the exact hostname users visit, not only the zone apex. Look at A, AAAA and, where relevant, CNAME. If you changed www.example.com but users browse example.com, or IPv6 still points to the previous host, the migration can look inconsistent even though one record is correct.
The checker also shows the TTL returned with an answer. TTL is the cache lifetime a resolver can apply to that record. Cloudflare's DNS documentation describes TTL as the field controlling how long records are cached and notes that a longer TTL can make updates take longer to appear to end users.
Step 2: compare independent recursive resolvers
Use the DNS Propagation Checker to compare Cloudflare, Google and the server resolver. Smart Web Utility does not pretend to sample a world map of geographic DNS nodes; it compares independent resolver views so you can see whether caches disagree.
| What you see | What it usually means | Next move |
|---|---|---|
| All resolvers return old IP | Old record may still be cached broadly, or authoritative DNS may still be old. | Confirm delegation and authoritative data. |
| Some old, some new | Resolver caches are at different stages. | Wait for the old cache lifetime; avoid random DNS edits. |
| All return new IP | DNS is probably not the remaining layer. | Check CDN, redirects, HTTP and TLS endpoint. |
| A is new, AAAA is old | IPv4 and IPv6 paths disagree. | Fix/remove the stale AAAA record if IPv6 is not intended. |
Step 3: make sure you changed the authoritative zone
Check the domain's NS records. The delegated nameservers determine which DNS provider is authoritative. If the parent zone delegates to a provider such as Cloudflare, Route 53 or a hosting platform, editing an unused DNS zone somewhere else changes nothing for public queries.
If the active authoritative source returns the new IP, recursive resolvers will eventually age out older cached answers. If it still returns the old IP, fix that source first.
Why lowering the new TTL does not erase an old cached answer
A resolver that already cached the old record uses the TTL attached to the answer it received at that time. Changing the record now to a lower TTL does not reach into existing resolver caches and rewrite their timers. Lower TTLs help most when set before a planned migration, allowed to age through existing caches, and then followed by the record change.
The same principle applies to negative caching. If a hostname did not exist and a resolver cached an NXDOMAIN or NODATA response, creating the record does not instantly invalidate that negative cache. RFC 2308 defines TTL behavior for cached negative DNS answers.
Step 4: separate DNS from routing, redirects and cached content
If independent resolvers all show the new IP, check what the destination actually returns. The HTTP Status Checker can confirm the responding IP, status and redirect location. The HTTP Header Checker can expose CDN or cache headers. The SSL Checker can help confirm which HTTPS endpoint is presenting the certificate when the connection verifies successfully.
A site can appear to be on the “old server” when DNS is already correct because a CDN still points to the old origin, the new server redirects to an old hostname, or the application itself serves cached content. Treat those as separate layers instead of changing DNS again.
A practical migration sequence
Before the change
Lower TTL far enough in advance for the previous higher TTL to expire. Inventory A, AAAA, CNAME, CDN and TLS dependencies.
During the change
Update the authoritative record once. Confirm the new server works before making additional DNS edits that can obscure the evidence.
After the change
Compare resolver answers, then test HTTP and HTTPS separately. Do not interpret old cached answers as proof that the authoritative zone is wrong.
After convergence
Raise TTL again if your availability strategy favors longer caching and you no longer need rapid migration changes.
What Smart Web Utility can and cannot prove
The DNS tools can show current answers from the resolvers they query and the TTLs returned with those answers. They cannot see every ISP, enterprise resolver, device cache or private DNS system on the internet. A matching DNS answer also does not prove that a CDN or application is routing to the intended origin.
Frequently asked questions
How long should I wait after changing an A record?
Use the previous record's cache lifetime as the starting point rather than a fixed “24–48 hour” rule. Different resolvers may refresh at different times. If authoritative DNS is already correct and one resolver still returns the old value, that resolver's remaining cache is the evidence that matters.
Why does mobile data show the new site but Wi-Fi shows the old site?
The two networks can use different recursive resolvers and different IPv4/IPv6 paths. One resolver may have refreshed while the other is still serving a cached answer.
Can flushing my computer's DNS cache fix it?
It can remove a local cached answer, but it cannot force an upstream ISP or public recursive resolver to discard its own valid cache entry.
Should I keep changing the DNS record until the site works?
No. Repeated edits make troubleshooting harder. First determine whether authoritative DNS, recursive caching or a non-DNS layer is responsible.