DNS Propagation: TTLs, Caches, and Verification

“DNS propagation” is shorthand for several systems reaching a consistent view after a change. The authoritative zone must serve the new data, recursive resolvers must stop using cached data, and clients must make a new lookup and connection.

The useful question is therefore not “Has DNS propagated?” but “Which layer is still returning the previous state?”

Capture the before state

Before editing a record, save:

• the old record type and value
• the proposed record type and value
• the current TTL
• the authoritative name servers for the zone
• the time the change will be made
• the rollback value and decision point

If the record did not exist, record that too. A cached NXDOMAIN response is negative caching, and it has different data from a cached positive A or CNAME answer.

Three places can disagree

Authoritative name servers

These servers publish the zone’s source data. Every authoritative server for the zone should return the intended record and compatible SOA data.

Recursive resolvers

Resolvers such as an ISP resolver, 1.1.1.1, or 8.8.8.8 cache answers for clients. Two resolvers can have learned the previous answer at different times, so their remaining TTLs can differ.

Clients and applications

Operating systems, browsers, local forwarding resolvers, proxies, and long-lived connections can preserve behavior after a recursive resolver has the new answer. A wrong certificate or origin response is also easy to mislabel as a DNS cache issue.

What TTL controls

TTL is the maximum cache lifetime attached to a DNS record response. A resolver that receives this answer may reuse it while the TTL counts down:

app.example.com.    300    IN    CNAME    new-target.example.net.

A 300-second TTL permits that cached answer to be reused for up to five minutes from when the resolver learned it. It does not guarantee that every client will refresh at the same instant.

Two operational details matter:

1. lowering TTL now does not shorten an old answer already cached with the previous TTL
2. an NXDOMAIN response can be cached according to negative-caching rules derived from the zone’s SOA data

For a planned migration, lower the TTL and then wait at least the old TTL before changing the target. That gives previously cached copies time to expire under the old policy.

Cloudflare adds a product-specific rule: proxied records use Auto, currently 300 seconds, and the value cannot be edited. DNS-only records can use Auto or a supported custom TTL.

Read the remaining TTL in the answer

Request only the answer section:

dig @1.1.1.1 app.example.com CNAME +noall +answer

A resolver might return:

app.example.com.    187    IN    CNAME    old-target.example.net.

The 187 value is the resolver’s remaining cache lifetime for that answer, not necessarily the TTL currently displayed in the authoritative DNS dashboard.

Run the same query again later. A decreasing value is consistent with a cached answer. A refreshed answer should show the new record and a reset TTL, subject to the authoritative value and resolver behavior.

Illustrated cache comparison

Illustrative example using reserved example domains and IPs. The following SVG is a constructed resolver comparison, not a capture of live DNS traffic.

Illustrative example using reserved example domains and IPs. It contains no customer hostname, resolver log, or production evidence.

The example demonstrates the diagnostic method: compare record values and remaining TTLs, then determine whether the difference originates at the authoritative or recursive layer.

Compare authoritative and recursive answers

First discover the zone’s actual authoritative servers:

dig example.com NS +short

Query each returned server directly, replacing the placeholder:

dig @<authoritative-name-server> app.example.com CNAME +noall +answer
dig @<authoritative-name-server> example.com SOA +noall +answer

Then compare recursive resolvers:

dig @1.1.1.1 app.example.com CNAME +noall +answer
dig @8.8.8.8 app.example.com CNAME +noall +answer

Interpret the results in this order:

Result	Interpretation
Authoritative servers disagree	Zone publication or authoritative-server consistency problem
Authoritative servers agree; recursive resolvers differ	Cached answers are at different ages
Recursive resolvers agree; one device differs	Local resolver, browser, VPN, or connection state
DNS answers agree; application still fails	Origin routing, TLS, redirect, or application configuration

Google Public DNS specifically recommends checking SOA serials when stale behavior persists, because different serials can reveal inconsistent authoritative servers.

Use a controlled change sequence

For a target migration:

1. lower an editable TTL in advance
2. wait for the old TTL window to pass
3. verify all authoritative servers still agree on the old value
4. publish the new value once
5. verify each authoritative server
6. compare at least two recursive resolvers
7. test TLS and the application through the public hostname
8. keep the previous destination available during the overlap when practical
9. raise the TTL after the service is stable

Avoid repeated edits while caches are converging. Multiple intermediate values make it difficult to identify which cached response a user received.

Know when it is no longer a DNS problem

DNS work is likely complete when independent recursive resolvers return the intended answer. Continue at another layer if:

• the certificate does not cover the hostname
• the server returns a default virtual host
• a redirect points to the old environment
• a webhook configuration retains the previous URL
• only an already-open browser session behaves differently
• the service behind the new address is unavailable

The subdomain endpoint guide covers host routing and TLS checks after DNS agrees. For an A-to-CNAME decision, use the record-type comparison before starting the cache window.

Flush only the cache you have identified

Google Public DNS offers a Flush Cache tool for supported names and record types. Use it only after the authoritative data is correct. For a stale CNAME chain, Google’s documentation instructs operators to flush CNAMEs from the last target back toward the queried name.

A flush at one public resolver does not clear ISP, enterprise, operating-system, or browser caches. Waiting for the applicable TTL remains the portable fallback, and delegation changes may require separate checks from ordinary record updates.

A practical completion test

Call the DNS portion of the change complete when:

• every authoritative server returns the intended data
• independent recursive resolvers have converged or their old TTLs are understood
• the public hostname establishes the intended TLS connection
• the application response and redirects are correct

This definition is more useful than a fixed “minutes” or “48 hours” promise because it is based on observable state.