Why a DNS Setting Change Shouldn’t Rebuild an Entire Zone

Changing one setting on a domain should not require rebuilding millions of unrelated DNS records. Yet that was the expensive path Cloudflare says its authoritative DNS pipeline took for some zone-wide settings. Its new planner chooses the smallest build it can prove safe, reducing unnecessary work while retaining the full rebuild when the system cannot establish that a narrower update is correct.

In a November 2 engineering post, Cloudflare says its Zone Builder now processes about 700 DNS record changes per second, plus roughly 100 other events such as zone-setting changes. Some customer zones contain more than 20 million records. The company reports that targeted builds for setting changes cut peak memory by 85%; the added headroom allowed it to shorten resilience waits, halving the time from a change to its data being written to Quicksilver, its internal distribution system. Those are Cloudflare’s production measurements, not a benchmark for every DNS provider or a guarantee of end-user cache refresh time. ^[1]

A zone setting has a wider blast radius than one record

An authoritative DNS service receives changes, reads the current zone state, builds the representation used by its serving infrastructure, and distributes the result. For a single record update, the affected object can often be identified directly. Cloudflare’s 2022 pipeline post described per-record builds as much faster than rebuilding a whole zone, and its new work extends that idea to zone-level events. ^{[1] [2]}

A setting change is harder. It may be emitted by different products, may not carry a precise explanation of which derived data it affects, or may affect shared state used by multiple zones with the same name. If the build planner guesses too broadly, it wastes memory and time. If it guesses too narrowly, it can leave stale or incorrect answers at the edge. Cloudflare says it built a planner that reasons about the dependency scope and chooses the least work it can establish is safe, plus a scheduler that combines work for the same zone. ^[1]

That “prove safe” condition is the heart of the engineering story. Incremental computation is not simply “update the changed row.” The system needs a dependency model: which outputs rely on which inputs, what events invalidate those outputs, and how to recover when an event is ambiguous. If the dependency graph is incomplete, a small build can be fast and wrong. A full rebuild is slower but often easier to trust.

Faster propagation is not the same as instant DNS everywhere

Cloudflare’s reported interval measures its pipeline through writing data to Quicksilver. DNS resolvers and clients still honor cache lifetimes and can retain previously fetched answers until their TTLs expire. An authoritative provider’s internal update time and a user’s observed cache refresh are different steps. Cloudflare’s explanation of authoritative DNS describes the authoritative server as the source that answers for a zone; it does not eliminate recursive resolver caching between that server and an end user. ^[3]

That distinction is useful during a migration. If a record change appears delayed, operators should check whether the authoritative answer has changed, then inspect the relevant resolver path and TTL behavior. A faster build pipeline can reduce one source of delay without making every cached copy vanish immediately.

The lesson for any event-driven system

The same design tension appears in search indexes, feature-flag propagation, configuration compilers, and materialized views. Full recomputation provides a simple correctness boundary, but its cost grows with total state. Incremental recomputation saves work, but only when the system can track dependencies and safely handle incomplete event metadata.

A robust planner needs an explicit fallback. When it cannot establish the impact of a change, recompute a larger scope rather than silently trusting an incomplete dependency map. It should also coalesce repeated work for one entity, expose queue delay and build scope to operators, and retain a way to compare an incremental result with a full rebuild. Those are general design recommendations drawn from the failure mode Cloudflare describes, not features asserted about its implementation beyond the published planner and scheduler.

Teams evaluating their own pipeline can ask three questions: What is the smallest independently valid unit? How does each event identify the outputs it invalidates? What is the correctness-preserving fallback when that answer is uncertain? Then measure both resource use and end-to-end freshness. A system that saves memory but increases stale-data incidents has not improved the service.

Cloudflare’s result is a reminder that optimization often comes from modeling correctness more precisely. The valuable change was not merely making a build smaller; it was teaching the pipeline when smaller was safe, and keeping a conservative path for everything else.