DNS Propagation Explained

DNS propagation is the informal name for the period when caches still hold old DNS answers after an authoritative change. The change is not actively pushed to all DNS servers worldwide; recursive resolvers refresh it when their cached copy expires or is evicted.

If you are starting from the broader term "cache," read What Is Cache first. This guide focuses on how DNS resolver caches make record changes appear gradually across the internet.

Check a DNS Change Now

Open the DNS propagation checker and compare the affected record across its available resolvers. Then query each authoritative nameserver directly to confirm the new value is published.

How DNS Propagation Works

DNS is a distributed, heavily cached system. Here's what happens when you change a record:

1. You update the A record for example.com from 192.0.2.1 to 198.51.100.1 in DNScale
2. The authoritative nameserver (DNScale) starts serving the new record
3. Recursive resolvers (like Google DNS, Cloudflare DNS, ISP resolvers) still have the old record cached
4. Each resolver keeps serving the old IP until its cached copy expires based on the TTL
5. After the TTL expires, the resolver fetches the new record from the authoritative server
6. Gradually, resolvers that previously cached the answer pick up the change

The normal cache window follows the remaining TTL of the old answer. Authoritative publication, parent delegation, negative caching, and application behavior can add separate delays.

The Relationship Between TTL and Propagation

TTL (Time to Live) is the single biggest factor controlling propagation speed. Every DNS response includes a TTL value that tells resolvers how long to cache the answer.

If your A record had a TTL of 3600 (1 hour), most resolvers will serve the old record for up to 1 hour after you make a change. If the TTL was 86400 (24 hours), it could take up to a full day. Use the TTL that was in effect before the change to estimate ordinary cache expiry. It is not a guarantee that every client will switch at that deadline.

This is a common point of confusion. If you change a record and set the new TTL to 300 seconds, but the old record had a TTL of 86400, resolvers that cached the old record will still hold it for up to 24 hours. The new TTL only takes effect once resolvers fetch the fresh record.

For detailed TTL strategies, see DNS TTL Best Practices.

What Affects Propagation Time

Resolver Caching Behavior

Not all resolvers respect TTL exactly:

• Some resolvers enforce a minimum TTL (e.g., they won't cache for less than 30 seconds)
• Some enforce a maximum TTL (e.g., capping at 24 hours even if you set 7 days)
• A few resolvers may cache slightly beyond the TTL

Resolvers may also use serve-stale behavior to preserve availability when fresh answers cannot be obtained. That is a separate condition from normal TTL expiry.

ISP DNS Servers

Compare the affected ISP resolver with the authoritative servers and other resolvers. An old result may come from an upstream cache, a stale local answer, split DNS, or inconsistent authoritative servers. Identify the source before attributing the delay to the ISP.

Nameserver Changes

A nameserver change updates the delegation in the parent zone, usually through your registrar. The parent NS and glue TTLs matter alongside the child zone's data. Changing a domain's nameservers does not normally change the root zone. Lowering the child SOA or record TTL does not lower the parent delegation TTL; keep old and new providers serving consistent data through the observed delegation window.

Negative Caching

If a resolver previously queried a record that did not exist, it caches the negative result (NXDOMAIN) using the smaller of the SOA record TTL and SOA.MINIMUM. Creating a new record after a negative cache entry means resolvers may still return "not found" until that negative cache expires.

Typical Propagation Times

How to Check DNS Propagation

Using dig

Query different DNS server types to see what they're returning:

# Query Google DNS
dig example.com @8.8.8.8
 
# Query Cloudflare DNS
dig example.com @1.1.1.1
 
# Query your authoritative server directly
dig example.com @ns1.dnscale.eu
 
# Check only the answer, short format
dig +short example.com @8.8.8.8
 
# Check the TTL remaining on the cached record
dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

If the authoritative server returns the new IP but public resolvers still show the old one, propagation is in progress. The remaining TTL in the resolver's response tells you approximately how long until that resolver refreshes.

Comparing Multiple Resolvers

# Quick propagation check across major resolvers
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "$ns: $(dig +short example.com @$ns)"
done

Checking Different Record Types

Propagation applies to all record types, not just A records. You can check MX records, TXT records, AAAA records, and others the same way:

# Check MX propagation
dig MX example.com @8.8.8.8 +short
 
# Check TXT propagation (useful for SPF/DKIM verification)
dig TXT example.com @1.1.1.1 +short
 
# Check AAAA propagation
dig AAAA example.com @9.9.9.9 +short

Online Propagation Checkers

Web-based tools like whatsmydns.net query dozens of resolvers worldwide and show results on a map. These are useful for a broad view but should be supplemented with direct dig queries to your authoritative servers for accuracy.

How to Speed Up DNS Propagation

1. Lower TTL Before Making Changes

The most effective technique. Reduce TTL at least one full old-TTL interval before your planned change. Start that interval after the authoritative servers publish the lower value:

# Step 1: Lower TTL to 300 (5 minutes), wait for old TTL to expire
example.com.  300  IN  A  192.0.2.1
 
# Step 2: Make the actual change
example.com.  300  IN  A  198.51.100.1
 
# Step 3: After propagation, restore a longer TTL
example.com.  3600  IN  A  198.51.100.1

This three-step process is especially important for migrations. If you are switching hosting providers, moving to a CDN, or changing email providers, lowering the TTL in advance prevents extended downtime.

2. Flush Your Local Cache

Flush your DNS cache if your device holds an old answer. Upstream recursive caches remain intact, so the next local lookup may still return cached data. Query the authoritative server directly to verify publication.

3. Use DNScale's Anycast Network

DNScale's anycast DNS network helps authoritative servers respond from geographically distributed points of presence. When a resolver's cache expires, it gets the fresh record from a topologically preferred DNScale node with low latency. This is typically more effective than unicast DNS setups where all queries go to a single location.

Common Propagation Misconceptions

"DNS propagation takes 24-48 hours"

This is a common planning window for nameserver changes, where parent-zone delegation TTLs and resolver caches matter. For regular record changes with short TTLs, most resolvers typically refresh in minutes, but outliers can happen because resolver behavior is not perfectly uniform.

"There's nothing you can do to speed it up"

Lowering the TTL before a change significantly reduces propagation time. With a 5-minute TTL, most resolvers will pick up your change within 5 minutes.

"Propagation means DNS servers are syncing with each other"

Recursive resolvers don't sync with each other. Each resolver independently caches records and fetches updates from authoritative servers when the cache expires. "Propagation" is really just caches expiring at different times.

"My site is down because of DNS propagation"

If your site is unreachable after a DNS change, check whether the issue is actually DNS-related or a web server misconfiguration. Use dig against your authoritative server to confirm the record is correct, then check public resolvers to determine whether it is a caching issue.

DNS Propagation and DNScale

When you update records in DNScale:

1. DNScale publishes the change to its authoritative serving infrastructure.
2. Verify the new value on the assigned nameservers; do not assume every location updates at exactly the same instant.
3. Recursive resolvers obtain the updated answer on a subsequent refresh.

Authoritative publication and recursive cache expiry are separate processes. Anycast improves reachability and query delivery; it cannot invalidate answers already cached by other resolvers.

Propagation and DNSSEC

If your zone is DNSSEC-signed, propagation involves an extra layer. DNSSEC signatures have their own validity periods, and key rollovers require careful timing to ensure that both old and new signatures are available during the transition. Rushing DNSSEC changes can cause validation failures at resolvers that enforce DNS security.

Conclusion

DNS propagation isn't a mysterious process -- it's mostly DNS caches expiring at different times around the world. By understanding TTL and planning changes in advance, you can minimize propagation delays. DNScale's anycast network and edge replication keep the authoritative side of propagation fast, while resolver caches still expire on their own timelines.

References

• RFC 2308: negative caching.
• RFC 8767: serving stale DNS data.