DNS Propagation: Why DNS Changes Take Time

DNS propagation is the window after a record change during which recursive resolvers, operating system caches and applications keep returning the old answer they already cached. Its length is set mostly by the TTL that was published before the change. A record served with a 3,600-second TTL can stay stale for up to one hour after you edit it. The real-world tail runs longer because some resolvers enforce TTL floors and some clients hold connections open without re-resolving.

Under the DNS caching rules in RFC 1035 and RFC 2308 (unchanged as of 2026), a resolver that cached a record with a 3,600-second TTL may keep serving the old answer for up to 60 minutes after the authoritative change. The 24 to 48 hour figure in registrar help pages applies only to delegation changes, because .com and .net publish NS records with a 172,800-second TTL.

What is DNS propagation, really

DNS propagation is cache expiry, not distribution. Authoritative servers answer with the new record within seconds of a zone update, but every resolver that fetched the old record keeps it until its TTL runs out. The internet "propagates" a change only in the sense that millions of independent caches expire on their own schedules, each starting from the moment it last fetched.

That reframing matters for planning. Nothing can be pushed outward faster. What you control is the TTL you publish before the change, the order in which you change records, and how long the old target keeps serving traffic after the switch.

Why DNS changes take time: the caches between your zone and the user

A single lookup can be answered from any of these layers, and each holds its own copy with its own expiry:

• Recursive resolvers run by ISPs, enterprises and public DNS services. Large public resolvers run many frontend caches that do not share state, so one name can be fresh on one node and stale on another.
• Forwarders and home routers, which often cache again and sometimes rewrite TTLs.
• The operating system stub resolver cache, which caches for the record TTL on most current platforms.
• Application caches. Browsers keep short-lived host caches (around one minute in Chromium-based browsers). The Java runtime caches successful lookups for 30 seconds by default, but older configurations with a security manager cache forever.
• Open connections. An HTTP/2 or keep-alive connection established before the change keeps sending requests to the old IP until it closes, no matter what DNS now says.

Resolver TTL handling: caps, floors and serve-stale

Resolvers do not always honor your TTL exactly. Many cap the maximum (Unbound defaults to 86,400 seconds, BIND to 7 days), which only shortens staleness. The dangerous setting is a minimum TTL floor: some resolver operators raise very low TTLs to several minutes to cut upstream query volume, so a 30-second TTL is not a 30-second guarantee.

Serve-stale (RFC 8767) adds another tail. When a resolver cannot reach your authoritative servers, it may keep answering from expired cache, and the RFC suggests a stale cap of 1 to 3 days. That only bites if the old authoritative servers go dark during a migration, which is exactly when operators tend to turn them off.

Negative caching: the change that breaks new hostnames

A name that did not exist is cached as NXDOMAIN for the lesser of the SOA record TTL and the SOA MINIMUM field, per RFC 2308. If someone queries cdn.example.com before you create it, every resolver that saw the NXDOMAIN keeps reporting the name missing for that period. Some managed DNS defaults put the SOA MINIMUM at 86,400 seconds, so check yours before a launch.

Delegation changes and the 48-hour parent TTL

Moving DNS hosting means changing NS records in the parent zone. The parent sets that TTL, not you: 172,800 seconds for .com and .net. Your zone's own NS TTL applies to resolvers that already learned the child-side records. DS record changes for DNSSEC follow the parent's DS TTL, commonly around a day, and a DS that points at a key the new provider does not sign with produces SERVFAIL rather than stale answers.

How DNS TTL controls the stale window

The DNS TTL is the maximum number of seconds a resolver may reuse an answer before asking again. The TTL in force before a change bounds staleness, so lowering a TTL only helps after the old, higher TTL has expired everywhere. A TTL lowered from 86,400 to 300 at noon still leaves day-long cached copies until noon the next day.

For a cutover model, assume resolver caches refreshed the record at uniformly random times, which is a reasonable approximation for large, unsynchronized resolver populations. At time t after the change, the fraction of caches still holding the old answer is 1 minus t divided by the TTL, reaching zero at t equal to the TTL. This blog's arithmetic for two common settings:

• TTL 3,600 seconds: 75% of caches still stale at 15 minutes, 50% at 30 minutes, 0% at 60 minutes.
• TTL 300 seconds: 80% stale at 60 seconds, 50% at 150 seconds, 0% at 5 minutes.

Real curves sit above this line. The residual comes from resolvers with TTL floors, clients pinned by long-lived connections, and embedded devices with bespoke caching. That residual is why the old target must keep serving well past the theoretical zero.

How to calculate DNS propagation time for a CDN cutover

DNS propagation time for a planned change equals the TTL in force before the change, plus a tail for TTL floors and connection reuse. Work out which record type you are changing first, because each has a different control point:

Record changes inside your own zone can be made near-instant with preparation, while delegation and DNSSEC changes carry parent-controlled windows you can only wait out.

A cutover procedure that keeps the stale window under five minutes

For a CDN or hosting switch done with a CNAME or A record change, this sequence bounds the theoretical stale window to the low TTL and handles the tail by keeping both targets live:

1. T minus (old TTL plus a margin): lower the record TTL to 300 seconds. With an old TTL of 86,400, do this at least 25 hours before cutover. Why: every cached copy of the long TTL must expire first.
2. Before cutover: create every new hostname on the new provider and validate it with a hosts-file override or by resolving the new target directly. Why: it avoids poisoning resolvers with NXDOMAIN and confirms TLS certificates and cache rules before real traffic arrives.
3. Warm the new edge for the hottest objects so the first wave does not stampede the origin.
4. Cutover: change the record. Confirm every authoritative nameserver returns the same SOA serial.
5. T plus 5 minutes to 24 hours: keep the old target serving identical content. Why: TTL floors and long-lived connections keep a residual trickle arriving there.
6. After the old target's request rate flattens near zero: raise the TTL back to 3,600 seconds or more and decommission.

A weighted DNS split removes most of the risk, because it turns the cutover into a ramp you can reverse in one TTL. BlazingCDN can run as a second CDN behind DNS with a weighted traffic split for multi-CDN cutovers, and zone onboarding with an engineer takes about one hour, so the new path can carry 5% of traffic well before the full switch.

Trade-offs and failure modes of low TTLs

Low TTLs are cheap insurance during a change window and a cost the rest of the time. The trade-offs worth weighing:

• Resolution latency. Each cache miss adds a recursive lookup, commonly tens of milliseconds and more on cold delegation chains. A 60-second TTL raises miss rates for long-tail users far more than for heavy users who keep the record hot.
• Authoritative query volume. Dropping a TTL from 3,600 to 60 seconds can raise query load at the authoritative tier by up to 60 times for the same resolver population, which matters on per-query DNS billing.
• Outage blast radius. With a long TTL, resolvers ride out a short authoritative outage on cached answers. With a 60-second TTL, an authoritative failure surfaces to users within a minute unless resolvers apply serve-stale.
• False confidence. TTL floors mean the published value is a request, and anything below roughly 60 seconds buys little extra control.

The observability gap is the hardest part: you cannot see resolver caches. The only reliable signal is traffic still arriving at the old target, which is why it must stay up and logged.

Verify this on your own stack

Query each authoritative nameserver directly with dig, recursion disabled, and confirm the SOA serial and the new record match on all of them. Query two or three large public resolvers repeatedly and read the TTL column: it should count down from your published value, and a reset to a higher number signals a floor. After cutover, chart requests per minute on the old target and compare the decay against the 1 minus t over TTL line; the gap above it is your residual from floors and connection reuse.

This approach fits teams moving CDN providers, origins or load balancers with record-level changes. It does not shorten NS migrations or DNSSEC key rollovers, where the parent zone's TTL sets the pace and the only lever is to run old and new providers in parallel for at least 48 hours.

FAQ: DNS propagation and TTL behavior

How long does DNS propagation take?

DNS propagation takes as long as the TTL that was cached before the change, so a 300-second TTL means about five minutes and a 86,400-second TTL means up to a day. Nameserver changes at the registrar take up to 48 hours for .com and .net because the parent zone sets that TTL, and some resolvers add a tail by enforcing TTL floors.

Does lowering the DNS TTL speed up propagation immediately?

Lowering a DNS TTL does not help immediately, because resolvers that already cached the record keep the old, longer TTL until it expires. Lower the TTL at least one full old-TTL period before the planned change, then make the change. With an original TTL of 86,400 seconds, that means lowering it more than 24 hours ahead of the cutover.

Why do some users still reach the old server after DNS propagation should be complete?

Users still reach an old server after DNS propagation mostly because of long-lived HTTP/2 and keep-alive connections that never re-resolve, plus resolvers that raise low TTLs to a minimum floor. Application caches, such as older Java configurations that cache lookups forever, add more. Keep the old target serving identical content until its request rate flattens near zero.

Is a 60-second DNS TTL safe for production traffic?

A 60-second DNS TTL is workable for short change windows but costly as a permanent setting. It multiplies authoritative query volume, adds recursive lookup latency for long-tail users, and exposes users to authoritative outages within a minute. Many teams run 3,600 seconds normally and drop to 60 to 300 seconds only in the day before a planned cutover.

Measure your residual DNS tail before the next cutover

Before your next migration, schedule a dry run on a low-risk hostname: lower its TTL to 300 seconds a full old-TTL period ahead, retarget it, and log per-minute request counts on the old target for 24 hours. Plot that decay against the theoretical straight line to zero at five minutes. The area above the line is your real-world tail from resolver floors and connection reuse, and it tells you exactly how long to keep the old origin or CDN alive in the production cutover.

If the cutover you are planning moves heavy video, software or large-file traffic, BlazingCDN offers a 14-day testing period on real production traffic at $5 per TB with the monthly minimum waived, enough to run this dry run through a weighted DNS split: start a BlazingCDN testing period for your DNS cutover.