DNS and domains
DNS propagation troubleshooting: a decision-first workflow
Learn how to separate a real DNS change from cache, delegation and local resolver problems without repeatedly changing records.
In short
A DNS change is not proven by one successful lookup. The useful question is whether authoritative servers publish the intended value, recursive resolvers are converging, and the application behind the record is ready. This workflow checks those layers in order so you do not create a second problem while trying to fix the first.
- Record the old value, new value, record type and expected TTL before editing DNS.
- Check authoritative nameservers before interpreting global resolver results.
- Treat mixed answers during the TTL window as evidence, not automatically as failure.
- Verify CNAME chains, DNSSEC and application readiness when the final value looks correct.
- Avoid repeated edits: each change restarts the investigation and may extend inconsistency.
1. Define the exact change
Write down the hostname, record type, previous value, intended value, TTL and the moment the change was saved. “The domain is broken” is too broad: the apex A record, a www CNAME, MX routing and a TXT verification record follow different paths and may fail independently.
Confirm that you edited the active DNS zone. The registrar may show one DNS editor while the domain delegates to nameservers operated elsewhere. A correct record in an inactive zone will never be returned publicly.
- Hostname and record type are exact
- Active authoritative nameservers are known
- Old and intended values are recorded
- Change time and TTL are recorded
2. Ask the authoritative servers first
Authoritative nameservers are the source for the zone. Query more than one of them. If they disagree, the issue is zone publication or nameserver synchronization—not ordinary propagation. If they all return the old value, wait for the provider to publish the change or review the zone you edited.
Also inspect the response code. NXDOMAIN means the queried name does not exist; NOERROR with no requested answer can indicate an empty response, delegation detail or a record type that is not present. A timeout is a reachability problem and should not be read as proof that the record is missing.
3. Compare recursive resolvers with the TTL in mind
Recursive resolvers cache answers to reduce latency and load. A resolver that cached the old answer shortly before your edit may keep it until the remaining TTL expires. That is why global checks can legitimately show both values for a period after an authoritative change.
Compare several independent locations and record the timestamp. A steady increase in the intended value is normal convergence. A stable regional split after the expected cache window deserves investigation into delegation, DNSSEC, geo-aware DNS or inconsistent authoritative answers.
4. Check the layers DNS does not prove
A correct address record only points clients toward a destination. It does not prove that TLS covers the hostname, the web server recognizes it, redirects are correct, the mail provider accepts the domain or the application is healthy. Test the destination separately after DNS returns the expected value.
For CNAMEs, follow the entire chain and confirm that every target resolves. For DNSSEC-enabled zones, a stale DS record or invalid signature can make validating resolvers fail even when a non-validating lookup appears normal.
- CNAME targets resolve to a final answer
- TLS certificate covers the hostname
- HTTP status and redirects are expected
- DNSSEC validation is healthy when enabled
5. Know when to wait and when to act
Wait when authoritative servers agree on the intended value and remaining differences fit the previous TTL. Act when authoritative servers disagree, delegation points to the wrong provider, the expected cache window has passed without convergence, or the destination service is not configured for the hostname.
Save a short incident note with the exact queries, locations, values and times. This turns “it works for me” into comparable evidence and gives a DNS provider enough detail to investigate without guesswork.
Next step
Check your own case
Frequently asked questions
Does DNS propagation always take 24 to 48 hours?
No. The practical window depends on previous cache state, TTL, provider publication and delegation. Many changes converge much sooner, while a delegation or DNSSEC problem will not be fixed merely by waiting.
Should I lower the TTL after the change?
Lowering it after resolvers cached the old value does not shorten that existing cache. For planned work, lower TTL before the change, allow the old TTL to expire, then restore a sensible value after stability.
Why does my computer show a different result?
Your device, router, ISP resolver, VPN or browser may use a different cache path. Compare the authoritative answer and multiple public resolvers before flushing local caches.
Can a propagation checker guarantee the site will work?
No. It can compare DNS answers. TLS, HTTP routing, application health, firewall rules and mail acceptance require separate checks.
Primary sources and reference
Sources consulted during editorial review. External links open the organization responsible for the standard or guidance.