Compare the intended active authority with the affected resolver for the exact name and type. Wait only when evidence supports ordinary caching; repair configuration or service failures at their owning layer.
When a DNS change seems to be taking too long, first check whether the authoritative nameservers publish the intended answer. Waiting helps an old cached answer expire; it does not fix a record saved in the wrong DNS account, a missing record or a broken DNSSEC chain.
There is no single countdown that tells you when every visitor will see a change. This guide gives website owners a way to separate normal caching from a configuration error, using official documentation checked on 13 October 2026. It does not require changing your DNS provider or buying a monitoring service.
Understand the three places you are comparing
The authoritative nameservers publish the domain’s DNS data. Recursive resolvers obtain answers for users and can cache them. Your device, application and network can introduce additional differences in how a hostname is resolved or which response is displayed.
For a useful investigation, write down the exact hostname and record type. example.com and www.example.com are different names. An IPv4 address record (A), IPv6 address record (AAAA), mail routing record (MX) and alias (CNAME) answer different questions.
| Observation | Likely investigation |
|---|---|
| Authoritative servers still publish the unwanted value | Check the active zone, record and provider save result |
| Authoritative servers disagree | Check zone deployment, delegation and provider consistency |
| Authoritative answer is correct; a resolver has an older answer | Inspect that resolver’s cached answer and remaining TTL |
| DNS answers are correct; the browser shows the old website | Check HTTP caching, redirects and the destination server |
| Validating resolvers return SERVFAIL | Investigate DNSSEC and authoritative service health |
These are starting points, not automatic diagnoses. Keep the actual answers and timestamps so that a provider can distinguish the cases.
Confirm that you edited the active DNS zone
The company where you bought the domain is not necessarily the company serving its DNS. Compare the nameservers delegated for the domain with the provider whose dashboard you edited. An inactive copy of a zone can accept edits that no ordinary visitor ever uses.
Check the full record name. Some dashboards expect a short label such as www; others show the complete name. Review the final saved record, not only what you typed. Also confirm the type and target; a value in an MX record will not move your homepage.
When moving DNS providers, do not assume an automatic scan found every record. Cloudflare’s record scan documentation explains its limits. Compare the new zone with an authorised export and the configuration required by your real website, email and verification services.
Our custom domain email guide is useful when the website works but mail no longer does. Web and email records should be reviewed separately before calling a migration successful.
Read TTL as a cache lifetime, not a global completion time
A DNS record’s time to live (TTL) controls how long an ordinary cached answer can be reused before it needs refreshing. If a resolver obtained the old answer shortly before your edit, it can retain that old value for the remaining lifetime. Different resolvers may have obtained it at different times.
Changing a record’s TTL now does not retroactively shorten copies already cached under the previous TTL. If you need a shorter transition for a planned change, reduce the relevant TTL in advance and allow the previous lifetime to pass before the change. Provider limits and nameserver delegation timings still matter; see Cloudflare’s TTL reference.
As a hypothetical example, a resolver that cached an old address with a one-hour TTL at 09:55 can normally retain it until around 10:55 even if you change the address at 10:00. A resolver fetching a fresh answer at 10:05 may already show the new value. This example explains the mechanism; it is not a guaranteed schedule for your domain.
A missing answer can be cached too
If someone queried a hostname before you created it, a resolver may retain the earlier negative answer. NXDOMAIN means the queried name does not exist. A no-data answer can instead mean the name exists but the requested record type is absent.
RFC 2308 describes negative caching and the role of SOA information in its lifetime. The new A record’s TTL does not simply overwrite a previously cached negative answer. This is why immediately creating and checking a new subdomain can produce different results across resolvers.
Resolution failures can also be cached under RFC 9520. Do not conclude that an error response must always be a fresh authoritative result. Record which resolver answered and the diagnostic details it provided.
Make a few read-only lookups
On Windows, Microsoft documents nslookup for querying DNS. The following examples read public DNS data; they do not edit a zone. Replace example.com with a public domain you are authorised to investigate.
nslookup -type=NS example.com
nslookup -type=A example.com
nslookup -type=AAAA www.example.com
nslookup -type=MX example.comRecord the responding server, result and time. Query the actual hostname your readers use. Testing only the root A record can miss a wrong www alias or an old AAAA record. If you use an online lookup tool, the domain you enter is disclosed to that tool; avoid entering private internal names.
A host or DNS administrator can compare responses from each authoritative nameserver with the recursive resolver used by the affected reader. Microsoft’s command supports selecting a server, but only use the server actually assigned to your domain when making that comparison. A direct authoritative answer is evidence about its zone contents, not proof that the parent delegation and DNSSEC chain are correct.
Treat SERVFAIL as a problem to investigate
SERVFAIL is not the same as “the new address has not propagated.” Google’s domain troubleshooting guide covers authoritative reachability, delegation and DNSSEC failures. A stale DS record after changing DNS providers can make validating resolvers reject the new answers.
If a diagnostic comparison without validation succeeds while validation fails, that is a clue to repair the trust chain, not a reason to tell all readers to turn security off. Ask the registrar and DNS operator to verify the parent DS record against the active zone’s DNSKEY and signatures.
Keep the exact failure and any extended diagnostic message. Repeatedly switching nameservers or adding random records can mix several changes into the same cache window and make recovery harder to reason about.
Check whether DNS is already correct
Once the intended DNS answer is present, test the website response separately. An old HTML cache, a redirect to another hostname, a browser service worker or the wrong site configured on the destination server can still display unexpected content. Clearing a WordPress page cache does not change a registrar delegation; changing DNS does not automatically configure the receiving website.
For a site with both root and www addresses, test both and their intended canonical redirect. Our www and canonical domain guide explains why the chosen public address needs consistent routing and links.
Do not demand that every public DNS tool display the origin server’s IP. A proxy or CDN can intentionally return its own addresses, and distributed services can return different valid endpoints. Compare with the configuration documented by your actual provider.
Why an expired TTL is not an absolute guarantee
DNS has resilience behaviour as well as ordinary caching. RFC 8767 allows stale data to be served in defined circumstances when fresh data cannot be obtained. Cloudflare also documents stale upstream responses as a troubleshooting case.
That does not make waiting indefinitely a useful plan. If the authoritative service is unhealthy, investigate it. If one resolver remains wrong after the expected ordinary lifetime, give its operator the exact name, type, answer and time. A map of green checkmarks is a sample of vantage points, not proof about every possible visitor.
Choose the next action from the evidence
- Wrong at the authority: correct the intended record in the active zone after checking the target.
- Correct authority, ordinary old cache: allow the relevant remaining lifetime and retest a small set of resolvers.
- Missing or inconsistent delegation: ask the registrar/DNS operator to verify the parent and assigned nameservers.
- DNSSEC failure: repair the trust chain with the operators rather than bypassing validation.
- Correct DNS, wrong website: investigate the HTTP, TLS and application configuration.
For a support request, include the hostname, record type, intended answer, change time, active nameservers and representative lookup results. Keep account credentials and private exports out of public posts. You will then have a specific problem to resolve, instead of restarting an arbitrary 48-hour wait.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Cloudflare: Records quick scanChecked An automatic scan is not a complete zone inventory.
Limits: Actual exports and service requirements remain necessary; no scanner is called comprehensive. - Cloudflare: Time to LiveChecked TTL defines record cache duration with provider-specific constraints.
Limits: No universal propagation deadline; the illustrated hour is hypothetical and old cached TTLs are not rewritten. - RFC 2308: Negative caching of DNS queriesChecked NXDOMAIN/NODATA caching and SOA-derived negative-answer lifetime.
Limits: Old optional failure-cache rules are not repeated as current guidance; RFC 9520 handles resolution failures. - RFC 9520: Negative caching of DNS resolution failuresChecked Resolution failures can be cached under updated requirements.
Limits: No implication that every failure is fresh or that waiting fixes its underlying cause. - Microsoft: nslookupChecked Read-only DNS querying, query types and optional server selection.
Limits: Examples use reserved example.com; no network settings are changed or private names solicited. - Google Public DNS: Domain troubleshootingChecked DNSSEC, stale DS/DNSKEY mismatches, delegation and authority reachability are distinct resolution failure causes.
Limits: Non-validating comparison is diagnostic, not a recommendation to bypass validation. - RFC 8767: Serving stale data to improve DNS resiliencyChecked Defined resilience behaviour can return stale data when refreshing fails.
Limits: Does not justify an indefinite wait or make every old answer legitimate. - Cloudflare: Stale response for upstream DNS resolutionChecked Stale responses are an explicit DNS troubleshooting case.
Limits: No assertion that any real Pagember or reader response was stale.