Cloudflare halves DNS build delay by targeting zones instead of rebuilding them whole
On November 2, 2026 Cloudflare detailed a targeted build planner for its DNS pipeline: instead of rebuilding zones with more than 20 million records on every setting change, it only rewrites what it can prove safe. Measured results: 40% fewer full builds, 85% less peak memory, and a halved median completion delay.
November 2, 2026. Cloudflare publishes an engineering post by Alex Fattouche on its DNS propagation pipeline. 700 changes per second. That is the Zone Builder’s current rate, up from roughly 250 in 2022, plus about a hundred zone-setting events. 20 million records. That is the size of the largest zones, heading toward hundreds of millions. Why it matters: until now, changing a single zone setting — enabling Universal SSL, for instance — triggered a rebuild of the entire zone, work that no longer fits in memory on the biggest ones.
The pipeline, and why full builds stopped scaling
A DNS zone is the collection of records and settings for a domain. Cloudflare turns every change into data its authoritative servers can use through a multi-stage chain: the change is written to a database, produces a Kafka event, passes through an aggregator, then the Zone Builder reads the zone state, converts it into keys the authoritative servers understand, and writes the differences to Quicksilver — the distributed key-value store that propagates configuration across the global network.
The original Zone Builder had one precious property: it did not need to know why a zone changed. It re-read the desired state from the database and rebuilt. The problem was never the event count, but the kind of work those events demanded, and how that work grows with zone size. A full build reads, encodes, and compares every record, holding the whole zone in memory. Cheap for a small zone. For a zone with tens of millions of records, it does not fit in memory at all.
The hard part is not writing less — it is proving less is safe
A targeted build must answer three questions a full build never asked: which DNS names can change, which shared metadata can change, and which prior state must be removed from Quicksilver. The rule governing the whole planner fits in one sentence, repeated in the post: every key a targeted build writes must be byte-for-byte identical to what a full build would have written. If the team cannot prove that, it does a full build.
The planner therefore distinguishes five build types:
- Resources only — rebuild records at specific names, leaving metadata untouched (the common case for A, AAAA, TXT, CNAME changes).
- Resources and metadata — for nameserver and wildcard changes.
- Apex and metadata — for settings such as Universal SSL, which touch the apex and CAA records.
- Purge — remove a zone that should no longer be published.
- Full zone — the fallback when nothing smaller can be proven safe.
The subtlety lies in same-name zones. A single public zone can map to several internal objects during onboarding and offboarding transitions, linked by a shared metadata key. A build that writes that key rebuilds it whole from a fresh view rather than patching an older copy.
Planning twice, and the scheduler
Another difficulty: an event describes the past. Between planning and execution, the database may have changed. Cloudflare therefore plans twice — a conservative work list when the event arrives, then a read of a publication snapshot right before writing. That re-read can turn a targeted build into a full build, into a purge, or skip it entirely, depending on the real state at execution time.
A unified scheduler replaces the two previous ones, merging work for the same zone before a build starts. On the Kafka side, the post stresses a point any pipeline operator knows: one slow build can delay unrelated customers. Kafka partitions are ordered, and the committed offset can only advance once every earlier message is done — hence soft committing, which prefers replaying work after a restart over losing a customer change.
Numbers, not intentions
The results are measured over 24 hours, running the new scheduler in a mirror against production. Over that window, 92.95% of builds avoided a full-zone rebuild — 86.81% of them as “resources only”. Full builds remain at 7.04%, a drop of roughly 40% from before.
The physical gains follow. Aggregate working-set memory fell from 49 GiB to 7 GiB on average (86% less), with peaks dropping from 79 GiB to 12 GiB (85% less). The median build completion delay — from a DNS change to the write into Quicksilver — fell from about 7.7 seconds to 3.3 seconds, a halving achieved by shortening two safeguards the reduced load finally made safe. On the tail, the largest p99 spike dropped from 14.6 minutes to 1.21 minutes, a 12-fold reduction.
What this teaches an SRE
The post is an engineering lesson that transfers well beyond DNS. The temptation, when a config-distribution pipeline costs too much on large objects, is to write less — and to discover in production that “less” leaves stale data behind. Cloudflare inverted the order: first prove equivalence (byte-for-byte equivalence tests, a production mirror, comparative sampling), and only then reduce the work. That is the difference between an optimization and a silent regression.
The full-zone fallback remains assumed, not shameful: a zone published for the first time must write every record, and an event that does not say what changed still gets a full build. The planner never turns uncertainty into less work.
Verdict
If you run a pipeline that distributes configuration at scale — DNS, firewall, CDN — and your large objects force expensive rebuilds, copy Cloudflare’s ordering: instrument an equivalence check first (full build versus targeted build, byte for byte), and only then reduce the targeted work, keeping the full fallback for whatever you cannot prove. The 85% peak-memory cut and the halved delay are the consequence of that discipline, not the starting point. If your zones are small and your builds already fast, the gain is marginal — but the equivalence rule is worth copying everywhere.