Repeatedly changing website DNS settings makes diagnosis harder because each new edit starts a fresh waiting period. DNS is the system that maps a domain name to the server that hosts the site, and resolvers keep serving the old answer until its saved timer runs out.
Authoritative DNS usually publishes an edit within seconds to minutes. The visible delay comes from caches elsewhere holding the prior answer. Every extra change replaces the answer under test and hides whether the first fix worked.
Table of Contents
- What happens after you save a DNS record?
- Why does another quick edit restart the wait?
- Why do two visitors see different versions?
- How do you tell a failed edit from normal caching?
- What is the safer way to make the change?
What happens after you save a DNS record?
The authoritative nameserver is the source of truth for the domain. Once all authoritative servers agree, the edit itself is done. What visitors see depends on recursive resolvers, the services that look up records for browsers and networks.
Suped explains that those resolvers continue serving the old cached answer until its old TTL expires, in how long DNS record changes take to propagate. TTL means time to live, measured in seconds. The practical baseline is to wait one full old-TTL interval. Suped gives the common examples of about 5–10 minutes for 300 seconds, an hour for 3,600 seconds, and up to a day for 86,400 seconds, in how long DNS record changes take to propagate.
Why does another quick edit restart the wait?
Each record carries its own cache lifetime. Changing the record again gives resolvers a newer answer with a newer timer. The problem is worse for a name that did not exist before.
A lookup can cache a negative NXDOMAIN or NODATA answer, meaning "does not exist." The IETF bounds that negative lifetime by the zone's SOA MINIMUM field in RFC 2308 on negative caching. Lowering TTL on the new record does not clear that old negative entry. Cloudflare documents that the resolver sees the new TTL only after the old negative entry expires, so repeated quick edits restart overlapping wait windows, in Cloudflare's DNS troubleshooting guide. The site can look broken when the real issue is an old "does not exist" answer.
Why do two visitors see different versions?
DNS answers are cached at multiple layers, including the browser, operating system, and recursive resolver. Reloading the website usually rechecks only the nearest layers. Different visitors also use different resolvers, with different cache contents and expiry times.
Cloudflare describes this layered lookup chain in what DNS is. During the window, one visitor can correctly reach the new server while another correctly reaches the old one. Switching the same record back and forth adds more versions to the mix. A marketing lead, developer, and client may each report a different result, all accurate for their own cache.
How do you tell a failed edit from normal caching?
Compare authoritative truth against recursive cache. Query each authoritative nameserver directly, then query public resolvers separately.
If the authoritative servers agree, the edit published. If resolvers still show the old value, the remaining task is waiting, not editing again. Changing nameservers during this check adds risk, especially with DNSSEC enabled.
- Query each listed authoritative nameserver directly with `dig @ns-name domain type`
- Query resolvers such as 1.1.1.1 or 8.8.8.8 for the same name and type
- Compare answers and TTLs across those results
- Treat an authoritative match with resolver mismatch as caching
What is the safer way to make the change?
Make one change, then leave the settings alone. Keep both the old and new hosting destinations working during the transition. Do not repeatedly switch authoritative nameservers while diagnosing. Cloudflare requires disabling DNSSEC at the registrar before replacing nameservers, otherwise validation fails and the domain becomes unreachable.
That failure looks like a larger outage than a slow record update. Flushing the local computer cache does not clear upstream ISP or public-resolver cache. A resolver may also serve stale data past TTL expiry when refresh fails. Wait the old TTL, keep both destinations live, then confirm again.
