A DNS change is not visible

What it means

If a DNS change is not visible, the cause may be a record edited in the wrong zone, a parent delegation pointing elsewhere, an incorrect owner or type, or a resolver returning cached positive or negative data. Do not assume that every old answer is evidence of a global DNS propagation delay. Establish what the authoritative zone currently says before waiting or flushing caches. Authoritative data Negative answers

This is a read-only troubleshooting flow; it does not mutate live DNS or promise a fixed time when all users will see a change.

Try it

Simulation — gather comparable evidence before choosing a cause. Select an incident, observe authority, resolver and delegation, and assess a hypothesis. The local history distinguishes what has been observed from what is merely selected. A correction cannot stand in for missing evidence.

In the cached-answer incident, authority has the new value while the resolver retains the old value until t=60. Observe both and the delegation, assess the cache hypothesis, then advance to expiry and requery the original question. In the unused-zone incident, waiting to t=120 still returns the old public value: a TTL cannot make the edited zone authoritative. Only a supported correction followed by a fresh observation can change that result.

Select the deliberately different mail question to see why nonmatching names/types cannot prove a discrepancy in the web record. Virtual time is bounded and cannot run backward within a rehearsal; Reset restores the initial cache incident, t=0, empty observations and no correction.

The fixture excludes prefetch and serve-stale, uses one controlled authoritative path and does not measure public DNS. Its result is an explanation of the supplied observations, not a diagnosis of your domain. Negative caching Serve-stale caveat

Environment, stop and rollback

Use the operational checks below only for a domain you administer or are authorized to investigate, from an approved network location. The command examples reference an already installed BIND 9.20.23 dig client; they read DNS and do not edit it. Record the exact question, server, response status, relevant records, TTL and observation time. A timeout is an expected possible observation, not evidence of a missing name. dig reference

Stop before a proposed change when the authoritative path is uncertain, observations refer to different names or types, or the change would touch mail, delegation or another service without specific authorization. Save the relevant prior RRset and configuration privately before an approved narrow repair. Verify the original question again after repair. If the repair is wrong, use the approved prior configuration and keep both required destinations available while caches expire; do not promise that restoring authority immediately rewrites every cache.

Diagnose in an order that narrows the cause

1. Fix the query scope. Write down the exact fully qualified owner, type (A, AAAA, CNAME, MX, etc.), expected value and DNS provider. www.example.com is not the same owner as example.com. Inspect both when the website uses both.
2. Establish delegation. Determine the child zone's nameservers from its parent and compare that list to the provider whose panel you edited. A zone existing in a dashboard does not prove the public DNS tree delegates to it. Zones and referrals
3. Ask the authorities. Query each actual delegated server for the record, noting response status, aa flag, any CNAME target, absence of the requested type, and mismatched values between servers. If they disagree, investigate the DNS operator's synchronization rather than guessing a universal TTL.
4. Ask a specific recursive resolver. Compare its answer, response status and remaining TTL for the same type. Different resolvers may have cached at different times. A returned value is not necessarily fresh just because the DNS panel changed.
5. Check negative caching and exceptional stale service. NXDOMAIN means name error, while NODATA means that the name can exist without that queried type. Both can be cached under rules involving SOA data; serve-stale is configuration-dependent. Negative cache rules
6. Verify other layers separately. If the correct address resolves, but the website fails, inspect reachability, TLS hostname/certificate and HTTP response; partial visitor failures have a broader cause list.

Optional read-only query examples

ISC BIND's dig accepts an explicit server with @server. The following are command patterns using example names and deliberately omit any actual production target. They need dig installed and outbound DNS access. They are not a live check. BIND dig reference

dig example.com. NS +noall +answer
dig @ns1.example.net www.example.com. A +norecurse +noall +answer
dig @resolver.example.net www.example.com. A +noall +answer

Replace both @ values only with known, authorized DNS servers discovered from delegation or local configuration; don't infer authority merely from the hostname ns1. For troubleshooting empty answers or failures, repeat without +noall +answer to view full status, authority section and aa flag. The parent-side delegation check is conceptually separate from querying the child's own NS RRset. Avoid destructive flush commands or repeated high-volume probing of public infrastructure.

Minimal fix and confirmation

If the authoritative zone is wrong, correct the exact owner/type through the authorized operator and verify all applicable authoritative servers. If the authority is correct but a resolver has legitimate cached data, maintain both endpoint versions if practical and check again after its observed cache lifetime; do not force a visitor's resolver to clear its cache. If the record was created after an NXDOMAIN response, account for negative caching. If failures persist past normal TTL, investigate authoritative reachability, resolver policy or serve-stale rather than asserting a guaranteed propagation window.

In practice

Record evidence as a small three-column log: delegation → authoritative answer → selected recursive answer, with type, TTL, server and time. It distinguishes publishing a change from observing it. For a controlled change procedure see Change a DNS record safely; for a single-resolver visualization see DNS TTL.

A failure is not an authoritative statement that a name is absent. Real resolvers also cache resolution failures under RFC 9520; that cache and its retry/backoff policy are outside this fixed diagnostic scene. Do not interpret repeated clicks as advice to hammer a failing nameserver. Failure caching

Key takeaways

Make the question comparable before interpreting the answer: same owner, type and relevant time. Check the delegated authoritative path as well as a recursive view. Wait only when the observed retained lifetime explains the discrepancy; a wrong zone, failed lookup or unrelated record needs a different next step.