How DNS Propagation Works

Introduction

When you update a DNS record — say, changing your domain’s A record from one IP address to another — the change doesn’t appear instantly across the internet. Instead, it travels through a layered caching system involving recursive resolvers, root nameservers, TLD nameservers, and authoritative nameservers, each holding copies of records for varying durations defined by the Time-To-Live (TTL) field. Understanding this pipeline is essential for anyone managing infrastructure migrations, CDN cutover events, or domain transfers, where stale DNS can silently route traffic to decommissioned servers.

DNS propagation is not a “push” mechanism — there is no central authority broadcasting record updates to all resolvers globally. It is fundamentally a cache expiry system. Resolvers only fetch fresh data after their cached entry expires. This means the propagation window is entirely controlled by the TTL values set on your DNS records before you make the change. A record with a 86400-second (24-hour) TTL will take up to 24 hours for all resolvers globally to see the update; a record pre-lowered to 300 seconds (5 minutes) will propagate within minutes.

Step-by-Step: The DNS Resolution Chain

flowchart TD
    A["1. Stub Resolver → Recursive Resolver"]
    B["2. Recursive Resolver → Root Nameserver"]
    C["3. Recursive Resolver → TLD Nameserver"]
    D["4. Recursive Resolver → Authoritative Nameserver"]
    E["5. TTL Caching and the Propagation Window"]
    F["6. Negative Caching (NXDOMAIN TTL)"]
    G["7. Anycast Resolver Pool Behavior"]
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G

Step 1: Stub Resolver → Recursive Resolver

When a client (browser, CLI tool, application) queries api.example.com, it first contacts its configured stub resolver — typically the OS resolver library. The stub resolver checks its local cache, and if the entry is absent or expired, it forwards the query to a recursive resolver (also called a full-service resolver). This is usually the ISP’s resolver (e.g., 8.8.8.8 for Google Public DNS, or 1.1.1.1 for Cloudflare). The recursive resolver is responsible for doing all the heavy lifting of the full lookup chain.

# See which resolver your system uses
cat /etc/resolv.conf

# Perform a full recursive trace
dig +trace api.example.com A

Step 2: Recursive Resolver → Root Nameserver

If the recursive resolver has no cached answer, it starts at the top of the DNS hierarchy: the root nameservers. There are 13 logical root nameserver addresses (A through M, e.g., a.root-servers.net), implemented across thousands of physical machines using Anycast routing. The same IP address (e.g., 198.41.0.4 for root server A) is announced from data centers on every continent; BGP routes your resolver’s query to the nearest instance. The root server doesn’t know the answer for api.example.com — it only knows which nameservers are authoritative for the .com TLD. It returns an NS record referral pointing to the TLD nameservers.

# Query the root directly
dig @a.root-servers.net com NS

Step 3: Recursive Resolver → TLD Nameserver

The recursive resolver now queries a TLD nameserver for .com (operated by Verisign, e.g., a.gtld-servers.net). The TLD nameserver holds the delegation records — the NS records that tell the resolver which authoritative nameservers are responsible for example.com. It returns those NS records (e.g., ns1.exampledns.com, ns2.exampledns.com) along with glue A records so the resolver knows their IP addresses without a bootstrapping problem.

# Query a .com TLD nameserver for example.com's NS records
dig @a.gtld-servers.net example.com NS

Step 4: Recursive Resolver → Authoritative Nameserver

The recursive resolver now queries ns1.exampledns.com directly — the authoritative nameserver for example.com. This server holds the actual zone file with all DNS records. It responds with the final answer: the A record for api.example.com pointing to, say, 203.0.113.42, along with the TTL for this record (e.g., 300 seconds). The resolver caches this response for the TTL duration and returns it to the stub resolver, which passes it to the client.

# Query the authoritative nameserver directly (bypass cache)
dig +norecurse @ns1.exampledns.com api.example.com A

# Full authoritative answer with TTL
dig api.example.com A +noall +answer

Step 5: TTL Caching and the Propagation Window

Each DNS record carries a TTL in seconds. When a resolver caches a record, it starts a countdown. Common TTLs:

• 300s (5 min): Appropriate for records you expect to change soon (during migrations)
• 3600s (1 hour): Standard for most production records
• 86400s (24 hours): Appropriate for stable records (MX, rarely-changed A records)

When you update a record, the old cached answers will continue to be served by resolvers until their TTL countdown reaches zero. The effective propagation window is equal to the TTL value that was set at the time of the change, not after. This is why the standard advice is: 24-48 hours before a migration, lower your TTL to 300s, wait a full TTL cycle for all caches to refresh with the short TTL, then make the change, and finally raise TTLs back after the migration is confirmed.

# Check current TTL of a record
dig api.example.com A | grep -i ttl

# Watch TTL countdown in real time
watch -n 5 "dig api.example.com A +noall +answer"

Step 6: Negative Caching (NXDOMAIN TTL)

DNS also caches negative responses — answers that say a record doesn’t exist (NXDOMAIN). Negative caching is governed by the SOA (Start of Authority) record’s MINIMUM field and the SOA’s TTL. RFC 2308 caps negative cache TTL at 3 hours. If you create a new subdomain, resolvers that have already cached a negative response for that name will continue to return NXDOMAIN until their negative cache entry expires.

# Inspect the SOA record for negative caching TTL
dig example.com SOA +noall +answer
# The last numeric field in SOA is the minimum TTL used for negative caching

Step 7: Anycast Resolver Pool Behavior

Commercial resolvers like 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare) are Anycast pools — thousands of edge nodes globally share the same IP address. This means two clients in different cities querying 8.8.8.8 may be routed to different physical machines, each with their own cache state. This is a key reason why the “24-72 hour propagation window” is stated as a range rather than a fixed number: different Anycast nodes may refresh their caches at different times.

# Identify which Cloudflare edge node responded
dig @1.1.1.1 api.example.com A
# Look at the "SERVER:" line in the output

# Compare resolution across multiple public resolvers
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo -n "$resolver: "; dig @$resolver api.example.com A +short
done

Key Takeaways

• TTL controls propagation speed: The DNS propagation window is bounded by the TTL value that was in effect before the change — always pre-lower TTLs to 300s before planned migrations.
• The resolution chain is hierarchical: Root → TLD → Authoritative nameserver, with each level providing referrals rather than answers until you reach the zone’s authority.
• dig +trace reveals the full chain: Running dig +trace api.example.com A shows every delegation hop from root to authoritative, invaluable for debugging propagation issues.
• Negative caching (NXDOMAIN) has its own TTL: Governed by the SOA MINIMUM field; new subdomains can appear to not exist for up to 3 hours on resolvers that cached an NXDOMAIN.
• Anycast resolver pools cause non-uniform propagation: Different edge nodes in a public resolver’s Anycast pool have independent caches, explaining why propagation appears different across geographic regions.