The core idea
There is no single global propagation switch.
Authoritative nameservers publish the current zone data. Recursive resolvers answer users and applications, often from a cached copy that remains usable until its TTL runs down.
After you change a record, a resolver with no cached copy may ask the authoritative servers immediately. Another resolver may continue returning its earlier cached answer. Both observations can exist at the same time without DNS itself being broken.
Cache lifetime
TTL is a ceiling for reuse, not a delivery countdown.
The authoritative record's TTL tells a resolver how long it may reuse that answer. The TTL visible in a recursive response often counts down from the value that resolver cached.
Before a planned change
Lower the TTL early enough for existing higher-TTL copies to expire. Changing the TTL at the same moment as the destination does not shorten copies already cached.
After the change
Leave the old destination available when possible until the previous maximum cache window has passed and observations support the cutover.
Negative caching
NXDOMAIN and other negative answers can also be cached. SOA timing influences how long a newly created name may still appear absent to some resolvers.
Expected divergence
Different answers have several possible causes.
- Cache age
- Resolvers learned the old and new value at different times, so their remaining TTL differs.
- GeoDNS or traffic policy
- An authoritative service intentionally returns different addresses based on query source, EDNS Client Subnet or routing policy.
- Authoritative inconsistency
- Not every authoritative nameserver serves the same zone serial or record set.
- Delegation mismatch
- The parent zone points to a different NS set than the child zone publishes, or required glue is stale or missing.
- DNSSEC validation
- A broken chain of trust can turn data that appears present at an authoritative server into a validation failure for recursive resolvers.
- Resolver behavior
- Prefetch, serve-stale, filtering and local policy can change how long or whether an answer is returned.
Troubleshooting sequence
Work from authority outward.
- 01
Confirm the exact owner name and type
Check the hostname you actually changed. TXT, DKIM, DMARC and SRV records commonly live below the zone apex.
- 02
Query every authoritative nameserver
Compare answer sets, SOA serials and DNSSEC responses directly. Repair authoritative disagreement before blaming recursive caches.
- 03
Check the parent delegation
Compare registrar or registry NS data with the zone's NS records, including glue for in-bailiwick nameservers.
- 04
Compare recursive observations
Use MyWebDNS to inspect returned values, resolver identity, node location and remaining TTL side by side.
- 05
Test the service separately
Once DNS is correct, verify TLS, HTTP, mail or the target protocol. DNS success alone does not prove application health.
Common questions
Short answers for frequent propagation problems.
How long does DNS propagation take?
There is no universal duration. Start with the previous TTL, negative-cache behavior and delegation TTL, then verify actual observations. Some resolver policies can retain or refresh data differently.
Why does my browser show the old site when DNS looks correct?
The browser, operating system, local network, VPN, proxy or application may have its own cache. The old server may also be responding behind the new address. Test the resolved IP and HTTP response separately.
Does 100% answer agreement mean the change is complete everywhere?
No. It means the answering probes in that MyWebDNS run returned matching complete answer sets. It does not sample every resolver or user network.
Should I flush a public resolver cache?
Only after confirming that the authoritative data and delegation are correct. Some resolver operators provide cache-purge tools, but a purge cannot repair incorrect authoritative records.
Primary sources
Technical references behind this guide.
This guide uses the DNS terminology and cache behavior defined in the standards below. Resolver products can add documented policies such as prefetch or serve-stale on top of the base protocol.