What is DNS propagation and how long does it take?

DNS propagation is the informal term for the time it takes for a DNS record change to become visible to all resolvers around the world. It is a slight misnomer — records do not "propagate" anywhere, because DNS is not a broadcast system. Instead, resolvers cache records for as long as the record's TTL allows, and "propagation" is really the staggered expiry of those caches as different resolvers refresh at different times.

The mechanism, accurately

When you edit a DNS record at your authoritative server, the change is immediate at that server. A resolver that has never queried the name will see the new value on its first query. A resolver that already cached the old value will keep serving that old value until its cache entry expires — after which it re-queries and gets the new value.

The worldwide visibility curve therefore depends on:

1. The TTL of the record at the moment it was cached.
2. Whether resolvers honor TTL (most do; a few override).
3. How recently each resolver queried your record.
4. Any registrar-level caching (for NS record changes).
5. Any operating system or browser cache in front of the resolver.

There is no push notification, no global database, no inherent delay on the authoritative side. If no resolver has the old value cached, a new record is "propagated" immediately.

Typical timeframes

• Most resolvers: the TTL value, usually 5 minutes to 24 hours.
• Worst-case public resolvers: up to TTL + a bit (some resolvers drift).
• Registrar-level NS changes: up to 48 hours because TLDs often cache at 24 hours and some ISPs cache beyond that.
• DNSSEC DS at the TLD: also up to 48 hours.
• Root-level changes: rare but can take days.

A record with a TTL of 300 (5 minutes) will typically be fully propagated inside 10 minutes. A record with a TTL of 86400 (24 hours) will take up to 24 hours. A record with a TTL of 172800 (48 hours) will take up to 48.

The pre-change TTL trick

If you know you are going to change a record, lower the TTL ahead of time. The sequence:

1. Today: the record has TTL 3600 (1 hour). You want to change it tomorrow.
2. Right now: edit the record to its current value but with TTL 300.
3. Wait at least 3600 seconds (the old TTL).
4. Now every cache has the record with TTL 300.
5. Make the actual change. Propagation takes 5 minutes.
6. After the change is stable, raise TTL back to 3600.

Doing this the day before a migration avoids long propagation windows during the actual cut-over.

What has no TTL and does not "propagate"

• NS record changes at the registrar: the TLD publishes these. It takes as long as the TLD's zone update cycle (often minutes for commercial TLDs, sometimes longer).
• Glue records: same as NS, with the added quirk that old glue at the registry can persist if the hostname moves between zones.
• Transfer pending: while a domain transfer is in progress, the new registrar has no authority over the zone. This is a legal/administrative wait, not DNS caching.

Verification

To check propagation, query multiple geographically distributed resolvers:

dig +short A example.com @8.8.8.8       # Google Public DNS
dig +short A example.com @1.1.1.1       # Cloudflare
dig +short A example.com @9.9.9.9       # Quad9
dig +short A example.com @208.67.222.222 # OpenDNS

Compare results. If they all show the new value, propagation is effectively complete from a public-resolver perspective. Corporate or ISP resolvers may lag further, but you cannot query those directly unless you are inside their network.

A specific quirk: some public resolvers ignore TTL and use their own minimum (e.g., treating any TTL below 60 seconds as 60). This is rare but real, and it means a query from inside a large DNS network might show a stale value for a minute longer than the record TTL suggested.

Why your change "did not propagate"

Common diagnoses when a record change appears stuck:

1. You edited the wrong zone. If your NS records point at provider A but you edited provider B, nothing changes. Verify NS records first.
2. Hidden secondaries. Some zones use hidden primaries with secondary nameservers; if only one secondary got the change, resolvers may hit the unchanged one.
3. TTL on the old record was high. You edited fast but the old record had 86400 TTL. Wait.
4. Local OS cache. Windows DNS client caches aggressively. On macOS, sudo killall -HUP mDNSResponder. On Linux, systemd-resolved --flush-caches.
5. Browser DNS cache. Chrome and Firefox have their own caches. Flush at chrome://net-internals/#dns or restart.
6. Registrar-level CNAME at apex. Some registrars flatten CNAMEs and re-resolve on their schedule, independent of your record's TTL.

Why short TTL is not always better

A 60-second TTL means every cache expires every minute, forcing resolvers to requery. On a high-traffic domain this can overwhelm your DNS provider or, more commonly, increase user-perceived latency because the first request after cache expiry pays a full resolution round-trip.

Rule of thumb:

• Stable records (A, AAAA, MX, NS): 3600 to 86400.
• Volatile records (during migrations, blue-green): 300 to 600.
• Always-changing records (GeoDNS, load balancers): 60 to 300, managed by the DNS provider.

DNSSEC and propagation

When a zone is signed, record changes generate new RRSIGs. The same TTL rules apply, but there is an additional subtlety: the signature has its own expiration time. If you change a record but the old RRSIG has not yet expired and has been cached, validators may briefly see a signed-but-inconsistent view until the RRSIG expires. Most signers mitigate this by publishing new RRSIGs with overlapping validity windows.

NS record changes specifically

Changing NS records at the registrar is the longest propagation event. Because the TLD zone serves your NS records, the TLD's TTL controls visibility. Many TLDs use 24 to 172800 second TTLs. Until the old NS records expire from caches, some resolvers still query the old nameservers — which may or may not have the latest records.

Best practice during a DNS provider migration:

1. Import the zone into the new provider.
2. Point both old and new at identical records.
3. Change NS records at the registrar.
4. Wait 48 hours with both providers serving identical data.
5. Then decommission the old provider.

When to use IntoDNS.ai

IntoDNS.ai runs DNS queries against 10+ public resolvers around the world and shows per-resolver results for A, AAAA, MX, NS, TXT, and other record types. If propagation has stalled, it tells you which resolver is still serving the old value — and whether the issue is cache lag or an actual NS misconfiguration pointing at the wrong zone.

Anycast and CDN-fronted DNS

Most modern authoritative DNS is anycast — a single IP announced from multiple locations. When a query for your authoritative nameserver hits the closest anycast site, the response depends on which node's zone data is current. A well-run anycast service propagates zone changes across all sites within seconds to minutes. A poorly run one can have stale nodes for minutes to hours after a zone update.

Cloudflare, Route 53, NS1, and Google Cloud DNS all advertise sub-minute global consistency for zone updates. Measure if you care:

dig +short example.com @ns1.yourdnsprovider.com
# compare with
dig +short example.com @ns1.yourdnsprovider.com +subnet=192.0.2.1/24

Different responses from the same nameserver IP mean different anycast sites are reporting different data.

When caching is aggressive

Some ISPs and corporate networks run resolvers that ignore TTL or apply a minimum TTL. Comcast historically ignored TTLs under 600 seconds. Some enterprise Microsoft DNS caches up to 24 hours regardless. Chrome's internal DNS cache is 60 seconds. Operating systems layer their own caches.

Full "propagation" for end users therefore depends on clients that are outside your direct view. If your monitoring shows 8.8.8.8 and 1.1.1.1 both serving the new record but users still reach the old server, the problem is client-side — either their ISP, their OS, or their browser.

Propagation for NXDOMAIN

Deleting a record takes as long to propagate as changing one. Negative caching (RFC 2308) is governed by the zone's SOA minimum field. If your SOA has minimum 3600, a deleted record's NXDOMAIN will be cached for up to 3600 seconds.

This matters when you, for example, delete a DKIM selector that is being signed with. Messages produced during the caching window will fail DKIM because resolvers still "know" the record does not exist.

The zone transfer view

If you have access to the authoritative zone or an AXFR, you see the authoritative state directly. Compare what you think is live against what AXFR returns:

dig @ns1.yourdnsprovider.com AXFR example.com

Most providers disable AXFR for security, but you can log in to the provider's UI or API and read the zone state. The on-record state is always current on the authoritative side; "propagation" is entirely a client-side cache problem.

Patience is the answer

Most "propagation is broken" tickets resolve themselves in under the original TTL. When in doubt:

1. Verify the record is correct at your authoritative nameserver.
2. Verify the nameserver is actually your live one (registrar NS matches).
3. Query from a third-party resolver (8.8.8.8, 1.1.1.1).
4. If all three show the new value and users still see old: the problem is downstream caching. Wait, or have them flush their resolver.