What Is DNS Propagation?
When you update a DNS record — changing an A record, adding a new CNAME, updating an MX record — the change does not take effect immediately for all users worldwide. DNS propagation is the process by which updated DNS records spread from your authoritative nameserver across the global network of DNS resolvers and caches.
Despite the myth of "up to 48 hours," most propagation completes in minutes for low-TTL records and hours for high-TTL records. The key factor is the TTL (Time To Live) of the record being changed.
TTL and Caching Hierarchy
Every DNS record has a TTL value (in seconds) that tells resolvers how long to cache the record before re-querying:
example.com. 3600 IN A 203.0.113.10
^^^^
TTL = 3600 seconds = 1 hourThe caching hierarchy:
- Browser DNS cache — browsers cache records for a short time (Chrome: 60s for positive, 15s for negative)
- OS DNS cache — the operating system maintains its own resolver cache (nscd, systemd-resolved, macOS mDNSResponder)
- Recursive resolver (ISP or public DNS like 8.8.8.8) — caches records up to their TTL
- Authoritative nameserver — the definitive source; returns the current record with no caching
When you update a record, the authoritative nameserver returns the new value immediately. But resolvers holding a cached copy will continue returning the old value until their cached TTL expires.
Recursive vs Authoritative Resolution
Authoritative nameserver: the server that holds the actual DNS zone file for a domain. When you update a record in your DNS provider's dashboard, the authoritative server is updated immediately.
Recursive resolver: the resolver your browser or OS queries (typically your ISP's resolver or a public resolver like 1.1.1.1). It does not hold zone data; instead it queries authoritative servers on your behalf and caches results.
Why Propagation Isn't Instant
The old record is cached in thousands of resolvers worldwide, each with their own copy and independent TTL countdown. When a resolver's cache expires, it re-queries the authoritative server and gets the new record.
Additionally, some resolvers do not respect TTLs exactly — they may cache records longer than specified (TTL inflation) or have minimum cache times.
Reducing Propagation Time
Before making a change: lower the TTL well in advance (24–48 hours before the planned change). By the time you make the change, most resolvers will have refreshed their cache with the short-TTL record:
# Before change: reduce TTL to 300 seconds (5 minutes)
example.com. 300 IN A 203.0.113.10
# After change propagates: set new value
example.com. 300 IN A 203.0.113.20
# After traffic stable: raise TTL back to 3600
example.com. 3600 IN A 203.0.113.20This is the standard pattern for zero-downtime DNS migrations.
Testing with dig and nslookup
# Query the authoritative nameserver directly (bypasses resolver cache)
dig example.com @ns1.exampledns.com
# Check what a specific public resolver sees
dig example.com @8.8.8.8 # Google
dig example.com @1.1.1.1 # Cloudflare
dig example.com @208.67.222.222 # OpenDNS
# Check TTL remaining in cache (the 'ANSWER SECTION' TTL decrements)
dig +nocmd +noall +answer example.com
# Trace the full resolution path
dig +trace example.comIf dig @ns1.exampledns.com returns the new IP but dig @8.8.8.8 still returns the old IP, propagation is still in progress.
Common Propagation Issues
Negative caching (NXDOMAIN TTL): if a record never existed, the NXDOMAIN (not found) response is also cached, typically for the SOA record's minimum TTL. Creating a new record takes longer to propagate because resolvers cached the negative response.
High SOA negative TTL: the SOA record's last field sets the negative cache TTL. Keep it low (300–600s) if you frequently add new records.
Cloudflare proxy caching: Cloudflare's proxy mode caches DNS at the edge separately from the origin DNS TTL. Changes to proxied records propagate within seconds on Cloudflare's network.