You migrated your website, updated its DNS, and confirmed that the new server is online. Yet your browser still loads the old site. A colleague sees the new version, while a customer in another location reaches the previous server or receives an error. This confusing split is usually described as DNS propagation, but the name can create the wrong impression.
DNS updates do not travel around the world as one synchronized event. Instead, recursive resolvers, operating systems, browsers, routers, and security services may reuse cached answers until their expiration times are reached. During that transition, different visitors can legitimately receive different IP addresses for the same hostname.
Understanding authoritative nameservers, recursive DNS, caching, and TTL values makes website migration DNS issues much easier to diagnose. It also helps you avoid downtime, certificate errors, and lost email when changing nameservers or moving a domain to a new server.
What DNS Propagation Actually Means
The Domain Name System translates hostnames such as example.com into information computers can use, including IPv4 addresses in A records and IPv6 addresses in AAAA records. When you change a record, you update the source of truth at the DNS provider. You do not directly update every resolver, device, or browser that has previously looked up the domain.
The phrase DNS propagation time refers to the transition period during which cached answers expire and fresh lookups begin returning the updated data. There is no central switch that changes all DNS responses simultaneously.
Authoritative DNS servers
An authoritative DNS server hosts the official records for a domain or DNS zone. If your domain uses Cloudflare nameservers, for example, Cloudflare is normally authoritative for records in that zone. When you modify an A record there, subsequent authoritative answers should contain the new value.
Recursive DNS resolvers
A recursive DNS resolver looks up DNS information on behalf of users. Internet service providers operate resolvers, as do public services such as Google Public DNS and Cloudflare’s 1.1.1.1. Modern browsers and operating systems may also use encrypted DNS through DNS over HTTPS or DNS over TLS.
After obtaining an answer, a recursive resolver stores it in its DNS cache. Later requests can be answered from that cache without contacting the authoritative server again. This improves speed and reduces DNS traffic, but it is also why DNS changes are not immediately visible everywhere.
How DNS TTL Controls Cached Answers
A DNS TTL, or time to live, tells resolvers how long a record may be cached. A TTL of 300 seconds allows an answer to be retained for approximately five minutes. A TTL of 14,400 seconds permits caching for four hours.
Suppose your old A record pointed to 192.0.2.10 with a four-hour TTL. Ten minutes before migration, a resolver cached that answer. Even if you immediately change the authoritative record to 198.51.100.20, that resolver may continue returning the old address for nearly another four hours.
Changing the TTL at the same moment as the IP address does not retroactively shorten existing caches. TTL planning must happen at least one previous TTL period before the migration. Some software may also apply minimum or maximum caching policies, while temporary negative answers can be cached when a hostname was previously missing.
Why Your Website Is Still Showing the Old Server
A website showing the old server after migration usually has one of several causes:
- A recursive resolver has the old A or AAAA record cached. Users relying on another resolver may already see the new server.
- The local device or browser has cached DNS information. Switching networks does not always bypass a browser’s encrypted DNS cache.
- A router or corporate network is caching the old answer. Managed networks may use filtering gateways or internal DNS zones.
- The old server is still behind a proxy or CDN. The DNS answer may be correct while cached web content makes the site appear unchanged.
- Only one hostname was updated. The root domain may point to the new host while www, api, or another subdomain still points to the old environment.
- An AAAA record was overlooked. IPv6-capable visitors may reach the old server through AAAA even though the A record points to the new IPv4 address.
- The local hosts file contains a manual entry. Hosts-file mappings override normal DNS resolution on that device.
These possibilities explain why “DNS changes not working” is not always a propagation problem. The first step is to identify the exact layer still returning or serving old information.
A Record Propagation vs. Nameserver Propagation
Changing an A record
With an A record change, the domain continues using the same authoritative DNS provider. Only the destination address changes. Once cached copies of the old record expire, resolvers query the same authoritative nameservers and receive the new IP. This is generally the simpler migration scenario.
Remember to inspect CNAME, AAAA, and modern HTTPS or SVCB records when applicable. A browser may use IPv6 or service-binding information that a basic IPv4 check does not reveal.
Changing nameservers
Nameserver propagation is more complex. When changing nameservers, you update the domain’s delegation through its registrar. The parent zone, such as the registry for a top-level domain, then directs resolvers to a different authoritative provider.
Resolvers may cache both the delegation and records obtained from the old provider. For a safe transition, the old and new DNS zones should contain matching records before the nameserver change. Keep the previous DNS service active until caches have expired and the new delegation has been verified globally.
If the new zone is missing MX, TXT, DKIM, CAA, or verification records, the website may work while email delivery, certificate issuance, or third-party services fail.
Cloudflare DNS Propagation and Proxying
Cloudflare DNS propagation can appear nearly immediate at its authoritative edge, but recursive resolvers may still hold the previous answer. Cloudflare’s proxied records add another layer: visitors receive Cloudflare anycast addresses rather than the origin server’s IP.
If the orange-cloud proxy is enabled, a normal lookup will not show whether the origin IP was updated correctly. Review the DNS record in the Cloudflare dashboard and confirm the origin configuration separately. Also check cache rules, redirects, edge certificates, and whether the new server accepts requests from Cloudflare.
Temporarily setting a record to DNS-only can help isolate origin issues, but it exposes the origin address and changes the traffic path. Make that change only when you understand its security and availability implications. Cloudflare provides additional background in its DNS learning resources.
How to Check DNS Changes Correctly
Reliable troubleshooting compares three things: the authoritative answer, results from multiple recursive resolvers, and the address used by the affected device.
First find the authoritative nameservers:
dig NS example.com +short
Then query one of them directly for the website record:
dig @ns1.dns-provider.example example.com A
If the authoritative response contains the old IP, the record was changed in the wrong zone, was not saved, or is managed somewhere else. If it contains the new IP, investigate resolver and local caches.
Compare public recursive resolvers
Use dig to ask different resolvers:
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
Also check IPv6:
dig @1.1.1.1 example.com AAAA +short
On Windows, equivalent checks include:
nslookup example.com 1.1.1.1
Resolve-DnsName example.com -Server 8.8.8.8
The remaining TTL shown by dig can indicate how long a resolver expects to retain its answer. Online DNS lookup tools are useful for comparing regions, but they represent selected probes—not every visitor or network. Google’s Admin Toolbox Dig offers a convenient browser-based lookup.
Confirm the server that answers HTTP requests
A correct DNS response does not prove the right virtual host or application is serving traffic. Test the new server directly while preserving the hostname:
curl --resolve example.com:443:198.51.100.20 https://example.com/ -I
This bypasses DNS for the test while sending the expected hostname and TLS Server Name Indication. It can reveal missing SSL certificates, incorrect redirects, or a web server configured for the wrong domain.
DNS Cache Flushing and Local Troubleshooting
DNS cache flushing can remove stale local entries, but it cannot clear a cache operated by an ISP or public resolver. Before flushing, compare the device’s result with authoritative and public-resolver answers.
- Windows: Run
ipconfig /flushdnsin an elevated Command Prompt. - macOS: Run
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. - Linux: For systemd-resolved, run
sudo resolvectl flush-caches. The command varies with the caching service.
Restart the browser if it maintains its own host cache, and inspect secure DNS settings to identify the resolver it uses. Test from mobile data and another network, but remember that different networks returning different answers is expected while old TTLs remain valid.
If every DNS tool returns the new address but old content still appears, clear or bypass the CDN and application cache. Check reverse proxies, load balancers, service workers, browser page caches, and database replication. That is a content-delivery issue rather than A record propagation.
Website Migration DNS Checklist
- Inventory all DNS records. Record A, AAAA, CNAME, MX, TXT, SRV, CAA, DKIM, DMARC, and service-specific entries.
- Lower TTLs early. Reduce relevant TTLs at least one existing TTL period before the move. Values around 300 seconds are commonly used temporarily.
- Build and test the new site first. Use a hosts-file entry or
curl --resolveto test without changing public DNS. - Install SSL before cutover. Ensure the certificate covers the root domain and required subdomains. Confirm automatic renewal works.
- Update A and AAAA records together. Remove obsolete IPv6 records if the new host does not support IPv6.
- Preserve email DNS. A hosting migration should not accidentally alter MX, SPF, DKIM, or DMARC records.
- Replicate zones before changing nameservers. Compare both providers carefully and verify DNSSEC settings. Incorrect DS records can make a domain fail validation entirely.
- Monitor both servers. Review access logs to see whether visitors still reach the old environment.
- Keep data synchronized. For dynamic sites, account for orders, form submissions, uploads, and database writes during the transition.
- Do not cancel old hosting immediately. Keep it online beyond the longest relevant TTL and confirm that traffic has stopped before decommissioning it.
- Restore normal TTLs afterward. Longer values reduce repeated queries once the migration is stable.
Frequently Asked Questions
How long does DNS propagation take?
DNS propagation time depends primarily on the previous TTLs and cached delegations. An A record with a five-minute TTL may update quickly for most resolvers, while longer TTLs can extend the transition for hours. Nameserver changes may take longer because delegation data is also cached. Claims that every DNS change always requires a fixed 24 or 48 hours are oversimplified.
Why do I see the new website while someone else sees the old one?
You may be using different recursive resolvers with caches created at different times. One resolver has already requested the new record, while the other still holds a valid cached answer. Different use of IPv4, IPv6, encrypted DNS, or a corporate DNS service can also produce different results.
Can I force DNS propagation worldwide?
No. You control the authoritative records and their TTLs, but you cannot remotely erase every resolver’s cache. Planning lower TTLs before migration, maintaining both servers during the transition, and verifying authoritative responses are the effective approaches.
Why does DNS show the new IP but my website still looks old?
The old content may be stored in a CDN, reverse proxy, application cache, service worker, or browser cache. The new server might also contain an older copy of the site. Use response headers, server logs, and direct-origin testing to identify which system produced the page.
When is it safe to cancel the old hosting account?
Wait until the longest old TTL and delegation cache have expired, DNS checks consistently return the intended destination, and old-server logs show no meaningful traffic. Confirm SSL, email, scheduled tasks, uploads, and database activity on the new environment before cancellation.
