Why Is My DNS Not Updating?
A DNS change that is not visible is often a cache, TTL, delegation, or wrong-zone problem—not necessarily stalled propagation.
How it works
Authoritative DNS publishes the intended record, while browsers, devices, networks, and public recursive resolvers can keep earlier answers until their caches expire. Start by confirming the authoritative zone and record before waiting.
Consider a change from 192.0.2.10 to 192.0.2.20. The authoritative nameservers can publish 192.0.2.20 immediately, while Resolver A continues returning 192.0.2.10 because it cached the earlier record twenty minutes ago. Resolver B, which has no cached answer, asks the authority and returns 192.0.2.20. Both answers can be legitimate until Resolver A's cache expires.
Begin with delegation, not a public checker. Ask which nameservers the parent zone delegates to, then inspect the record on that authoritative provider. If the active nameservers are different from the dashboard you edited, this is a configuration issue. Waiting for propagation will not copy a record from the wrong zone into the correct one.
Check the exact query name and type. A visitor may reach api.example.com through an AAAA record even after the A record changed, or a CNAME can lead to a target whose address is still old. A web host may also return a different address intentionally through a CDN or geo-aware DNS service. Compare the answer with the service's intended routing before replacing records.
Local caches are useful only after authority is confirmed. A browser may retain connections, an operating system may cache DNS, and a workplace network may use its own resolver. Testing in another network or with several public resolvers distinguishes a local observation from a global DNS issue. Do not keep changing records while collecting evidence; each change makes the timeline harder to understand.
A newly created name can look absent because negative answers are cached. If a resolver recently received NXDOMAIN or no-data, it can retain that response for the zone's negative TTL. When the authoritative answer and most public resolvers show the new value, waiting is reasonable. When the authority, nameserver delegation, or selected record type is wrong, correct the configuration instead.
What the symptom usually means
Different resolvers can legitimately return different answers after a change because they cached the older value at different times. TTL limits how long a resolver may normally reuse that answer. Negative caching can also preserve a recent no-record response after you add a new name.
A result can differ for reasons other than cache. CDNs and load-balanced DNS may intentionally return different addresses by resolver location. An A record can be correct while an AAAA record, CNAME target, or related MX/TXT record remains old.
Common causes
Check that you edited the zone actually delegated by the domain's NS records. It is common to update an old registrar zone while the active DNS provider hosts the authoritative nameservers. A typo, an unexpected CNAME, or editing www when the application uses the apex can create the same symptom.
Lowering TTL helps only when done before a planned change; it cannot erase cache entries created under the earlier TTL. Browser, operating-system, and office-network caches can outlive a quick test, so compare several independent resolvers before clearing local state repeatedly.
Troubleshoot in order
First inspect the authoritative nameservers and the exact hostname and record type. Then compare A, AAAA, CNAME, and any relevant TXT or MX data with a DNS lookup. Confirm the destination server is ready before moving traffic. Keep a short timeline of the prior value, new value, and TTL.
Use the propagation checker to compare public resolver answers. Agreement is useful evidence, but it is not proof that every ISP worldwide has refreshed. If the authoritative answer is already wrong, waiting will not help; correct the zone or delegation. If it is correct and resolvers differ, waiting is usually appropriate.
Practical guidance
- Verify the authoritative zone before treating the issue as propagation.
- Check A and AAAA separately and follow any CNAME target.
- Compare public resolvers before clearing only your local cache.
Common question
Why does one device work while another does not? They may be using resolvers with different cache ages, network policies, or address-family preferences.