DNS Propagation

DNS propagation is the period during which DNS changes spread across recursive resolvers and cached systems worldwide. A record can update immediately at the authoritative DNS provider while some visitors still receive the previous answer from a local cache. The difference reflects normal caching behavior, not the physical transfer of data between every DNS server.

How DNS propagation works

When a user requests a domain, a recursive resolver checks whether it already has a valid cached answer. If the record remains within its Time to Live, or TTL, the resolver can return that answer without querying the authoritative nameserver again. After the TTL expires, the resolver requests fresh data and stores the new response.

This decentralized process means different users can receive different answers during a DNS change. One resolver may refresh within minutes, while another continues serving an older cached response until its TTL ends. Browser, operating-system, router, internet-provider, and public-resolver caches can each influence what a user sees.

What controls the update time

The record’s previous TTL is the main factor. Lowering the TTL before a planned change shortens the period that resolvers may retain the old value. Changing the TTL at the same time as the destination record does not invalidate answers that are already cached under the earlier value.

Nameserver changes behave differently from ordinary record updates. The parent registry publishes the domain’s delegation, while recursive resolvers may cache both the delegation and records from the previous provider. A migration must keep the old DNS zone available until cached delegation data expires.

Resolver policies can also affect timing. Most resolvers honor published TTL values, but some enforce minimum or maximum cache periods. Negative answers have their own cache duration, so a recently created record may continue returning a “not found” response until the negative cache expires.

How long DNS propagation takes

Many record changes become widely visible within minutes or several hours. Nameserver changes can take longer because registry data and cached delegations are involved. A fixed global completion time cannot be guaranteed because each resolver refreshes independently.

The correct estimate comes from the old TTL, not a generic 24-to-48-hour rule. If an A record had a four-hour TTL before it changed, compliant resolvers can serve the old address for up to four hours after their last lookup. A resolver that cached the record immediately before the update may retain it for nearly the full period.

How to prepare for a DNS change

Reduce the relevant TTL at least one full TTL period before the planned change. Confirm the lower value is visible from the authoritative nameservers, then wait long enough for older cached copies to expire. Make the destination change only after that preparation period.

Keep the previous service operational during the transition. For a website migration, both servers should answer correctly while caches refresh. For email changes, maintain the old mail route and avoid removing required MX, SPF, DKIM, or DMARC records prematurely.

When changing nameservers, copy the complete zone to the new provider before updating the delegation. Compare all record types, including less visible verification and service records. A missing record can affect email, certificates, subdomains, or third-party integrations even when the main website works.

How to verify DNS propagation

Query the authoritative nameservers first to confirm they return the intended value. Then compare responses from several recursive resolvers. The Google Public DNS documentation explains how a public resolver handles client queries, while command-line tools such as dig or nslookup show the returned record and remaining TTL.

Test the exact hostname and record type that changed. Checking the root domain does not verify a www, mail, or verification record. If results differ, inspect which resolver answered, whether its TTL is counting down, and whether the domain’s delegation points to the expected authoritative servers.

Troubleshooting delayed updates

Confirm that every authoritative nameserver returns the same zone data. Inconsistent servers can produce intermittent results that resemble slow DNS propagation. Check for stale records at the old provider, incorrect glue records, DNSSEC validation failures, and local hosts-file overrides.

Flushing a device’s DNS cache affects only that device. It cannot clear caches operated by internet providers or public resolvers. When the authoritative data is correct, the safest response is usually to keep both destinations available and allow the remaining TTL to expire.