Authoritative nameserver
Holds the definitive zone data for the delegated domain and answers from that configured source.
DNS Propagation: Why Some Resolvers Still Return the Old Record
What people call DNS propagation is usually a combination of authoritative DNS changes and many independent recursive caches expiring at different times. Two resolvers can temporarily return different valid views of the same hostname.
DNS changes are not a global push
When you edit an A, AAAA, CNAME, MX or other DNS record, the authoritative source changes first. Recursive resolvers around the internet do not receive an instant broadcast telling them to discard every cached answer. A resolver that already cached the previous record can continue using it until its cache policy requires a refresh.
RFC 1035 defines TTL as the interval a resource record may be cached before the source should be consulted again. Modern recursive resolvers implement that principle while also applying operational policies, and standards such as RFC 8767 allow stale data to be served in limited resilience scenarios when fresh authoritative data cannot be obtained.
Authoritative DNS versus recursive DNS
Recursive resolver
Looks up answers on behalf of clients and caches results so later requests can be answered faster.
Local/client cache
Operating systems, browsers, routers and applications can add another cache layer beyond the recursive service.
CDN/application layer
Even when DNS is correct, a CDN or application can still route or serve content from an older origin. That is not a DNS propagation problem.
Step 1: compare independent resolver answers
Use the DNS Propagation Checker to compare Cloudflare, Google and the server resolver. These are separate resolver paths with separate caches. If one shows the new value and another shows the old value shortly after a change, cache state is a plausible explanation.
The checker intentionally does not claim to sample every country or ISP. Three independent answers are useful evidence, but they are not proof that every resolver worldwide has converged.
Step 2: inspect the current record and TTL
Use the DNS Checker to inspect common record types and the TTL returned by its resolver. Cloudflare's DNS documentation describes TTL as the field controlling how long records are cached and notes that longer TTLs can make updates take longer to appear to end users.
The important value after a change is often the previous cache lifetime. If a resolver cached the old answer before you lowered the TTL, the new lower TTL does not retroactively rewrite the timer on that existing cache entry.
Step 3: verify the authoritative configuration
If every recursive resolver keeps returning the wrong value, do not assume you simply need to wait longer. Check the domain's NS delegation and confirm you edited the DNS zone that is actually authoritative. A common mistake is changing records at a registrar while the domain is delegated to another DNS provider.
If some authoritative nameservers themselves disagree, recursive resolvers can receive different answers depending on which authority they reach. Google Public DNS troubleshooting guidance recommends checking SOA serials when stale answers persist because inconsistent authoritative servers can be the underlying problem.
Why resolvers can disagree temporarily
| Observation | Likely explanation | What to do |
|---|---|---|
| Cloudflare new, Google old | Independent caches refreshed at different times. | Check previous TTL and wait for the old cache to expire if authoritative DNS is correct. |
| Both public resolvers old | Old cache may still be valid, or authoritative DNS may still be old. | Verify delegation and authoritative zone data. |
| All resolvers new, one device old | Local OS/router/browser cache or a different configured resolver. | Identify the resolver path used by that device/network. |
| A new, AAAA old | IPv4 and IPv6 records were not updated together. | Fix or remove the stale AAAA record if IPv6 is not intended. |
| DNS new, website still old | CDN/origin routing, redirect or application cache. | Move to HTTP/SSL diagnostics instead of editing DNS again. |
Negative caching can delay newly created records
DNS caching is not limited to successful answers. A resolver can cache a negative result such as NXDOMAIN or NODATA according to DNS negative-caching rules. If a hostname did not exist and you create it moments later, some clients can still receive the cached negative answer until that cache expires.
This is why “the record exists now” does not necessarily mean every resolver will immediately stop returning the earlier negative response.
Serving stale data is a special case
TTL is the normal freshness boundary, but RFC 8767 allows recursive resolvers to serve expired cached data in exceptional situations to improve resilience when fresh authoritative data cannot be retrieved. If you are debugging a rare stale-answer case during an authoritative outage, do not assume every resolver must discard the old record at the exact TTL boundary.
Do not keep editing the record while diagnosing
Repeated DNS changes can reset your own troubleshooting baseline and create more generations of cached answers. Once the intended authoritative data is correct, observe resolver behavior before making another change. If the problem persists beyond the expected cache window, investigate delegation, authoritative consistency, CNAME chains, A/AAAA differences and non-DNS routing layers.
What Smart Web Utility can and cannot prove
The propagation checker compares current answers from Cloudflare, Google and the server resolver for supported A, AAAA, MX, TXT, CNAME, NS and CAA queries. It does not query every geographic resolver, expose each resolver's remaining cache TTL, or directly audit all authoritative nameservers.
The DNS Checker can show TTL with the answer returned by the resolver it queries, but that TTL is evidence about that current response—not a universal countdown shared by every resolver worldwide.
Frequently asked questions
How long does DNS propagation take?
There is no single universal duration. The previous TTL, when each resolver cached the answer, negative caching, resolver policy and authoritative consistency all affect what different users see.
Why does 1.1.1.1 show the new IP but 8.8.8.8 shows the old IP?
They are independent recursive resolver systems. One may have refreshed after your DNS change while the other still has a valid cached answer.
Can I force every resolver to refresh immediately?
No. You can correct authoritative DNS and, for some public resolver services, use provider-specific cache-flush tools, but you cannot remotely purge every ISP, enterprise or local DNS cache on the internet.
Does a low TTL guarantee instant changes?
No. It reduces the normal maximum caching interval for new answers, but existing caches may have been populated under an older TTL and exceptional stale-serving behavior can exist.