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.

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

This process typically takes minutes to 48 hours, depending on the TTL and resolver behavior.

Propagation is not a push mechanism. No central authority tells resolvers to update. Each resolver independently decides when to refresh its cache based on the TTL it received with the last response.

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. The math is straightforward: the maximum propagation time equals the TTL that was in effect before the change, not the TTL you set on the new record.

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

Google Public DNS (8.8.8.8) respects TTLs fairly strictly, while some ISP resolvers take liberties with caching duration.

ISP DNS Servers

ISP-operated DNS resolvers sometimes cache more aggressively than public resolvers like Google (8.8.8.8) or Cloudflare (1.1.1.1). Users on these ISPs may see slower propagation. If your users report seeing old DNS data long after a change, it is usually an ISP resolver holding a stale cache.

Nameserver Changes

Changing nameservers (e.g., migrating to DNScale) involves the domain registrar, TLD servers, and root servers. This is the slowest type of DNS change, often taking 24-48 hours because NS records at the TLD level typically have long TTLs. The SOA record at the parent zone controls some of this timing.

Negative Caching

If a resolver previously queried a record that did not exist, it caches the negative result (NXDOMAIN) based on the SOA minimum TTL. 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 24-48 hours before your planned change:

# 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 to see the current answer from your own machine after local cache is cleared. This doesn't speed up global propagation, but lets you verify changes locally.

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. The change takes effect on DNScale's authoritative servers within seconds thanks to direct database replication (not traditional zone transfers)
2. All DNScale edge nodes worldwide are updated simultaneously
3. Resolvers that query any DNScale node will get the new record as soon as their cache expires

This is faster than providers that rely on AXFR/IXFR zone transfers between servers, which can add additional delay before the authoritative servers themselves are consistent.

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.

Related Topics

• DNS Cache Explained -- where DNS answers are cached and how stale answers expire
• What Is TTL -- how TTL controls caching duration
• DNS TTL Best Practices -- recommended TTL strategies for different scenarios
• How to Flush DNS Cache -- clear your local cache before local verification
• What Is an SOA Record -- SOA timing parameters affect zone transfer behavior
• DNS Record Types -- overview of all DNS record types and their propagation characteristics
• Domain Registrar vs DNS Hosting -- understand where nameserver changes happen

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.