Send, receive, and shield emails with PostScale. One API, EU-hosted. PostScale

    DNS Propagation Explained

    Understand what DNS propagation is, why DNS changes take time to spread across the internet, and how to check propagation status for your domain.

    What you'll learn

    • Understand how DNS caching drives propagation timing across recursive resolvers
    • Learn the relationship between TTL values and propagation speed for different record types
    • Use dig and other tools to check propagation status from multiple vantage points
    • Apply pre-change TTL reduction strategies to minimize downtime during DNS migrations

    DNS propagation is the time it takes for DNS changes to spread across all DNS servers worldwide. When you update a DNS record, the change doesn't take effect instantly everywhere — resolvers around the world are still serving the old cached version until their cache expires.

    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) immediately serves 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, all resolvers worldwide 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

    Change TypeTypical TimeWhy
    Record update (A, CNAME, MX, etc.)Minutes to hoursDepends on the previous TTL
    New record addedNearly instantNo old cache to expire
    Record deletedMinutes to hoursOld cached entries must expire
    Nameserver change24-48 hoursTLD NS records have long TTLs
    TTL reductionUp to the old TTLResolvers cache at the old, longer TTL first

    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 changes immediately on your own machine. This doesn't speed up global propagation, but lets you verify changes locally.

    3. Use DNScale's Anycast Network

    DNScale's anycast DNS network ensures that your authoritative servers respond quickly from geographically distributed points of presence. When a resolver's cache expires, it gets the fresh record from the nearest DNScale node with minimal latency. This is 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 the maximum for nameserver changes. For regular record changes with short TTLs, propagation typically completes in minutes.

    "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.

    Conclusion

    DNS propagation isn't a mysterious process -- it's simply 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 instant edge replication ensure that the authoritative side of propagation is as fast as possible.

    Ready to manage your DNS with confidence?

    DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

    Start free