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

Example — interpret three observations. This table is a fabricated illustration; no DNS queries have been performed.

In the last case, the negative answer may have its own cache lifetime, not the TTL on the newly added A record. A resolver configured for conditional serve-stale can also retain expired information during authoritative resolution failures. Negative cache Serve-stale caveat

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.