Cloudflare Cuts DNS Build Work With Targeted Zone Builds: 92.95% of Builds Skip a Full Rebuild, Average Memory Falls From 49 GiB to 7 GiB in Its Own Measurements

On November 2, 2026, Cloudflare published an engineering post by Alex Fattouche on how it cut the work its DNS Zone Builder does after a change. The Zone Builder turns changes to DNS records and zone settings into data that Cloudflare's authoritative DNS servers can use, and writes it to Quicksilver, the distributed key-value store that spreads it across the network. When the author last wrote about this pipeline in 2022, the builder received about 250 record changes per second. Today it receives about 700, plus about 100 other events such as zone setting changes. The post says the number of events was never the real problem. The problem was the kind of work some events needed: some zones now hold more than 20 million records, and Cloudflare expects them to grow toward hundreds of millions.

The old design had one useful property. A full build did not need to know why a zone changed. It read the zone and every record, converted them into Quicksilver keys, compared them with what was stored, and wrote only the difference. That is cheap for a small zone, but it still reads and compares every record and holds the whole zone in memory. A zone setting change, such as enabling Universal SSL, can alter metadata and certification authority authorization records at the zone apex, yet the event often did not say what had changed. So Cloudflare changed event producers to include the changed fields with previous and new values where available, and built a planner that chooses the smallest build it can prove is safe.

The planner picks one of five build types: resources only, resources and metadata, apex and metadata, purge, and full zone. The rule stated in the post is strict: every key a targeted build writes must be byte-for-byte identical to what a full build would write, and if that cannot be proven, the system does a full build. Missing details, unknown events and timestamp-only updates still cause a full build, so uncertainty never turns into less work. Cleaning old state works as in 2022: record events include deleted records and previous versions, and the builder scans Quicksilver for existing keys under each rebuilt name and removes the stale ones. One deliberate exception exists for the largest zones. Above a fixed record-count threshold the builder never escalates to a full build, because such a build cannot finish and would hold back other changes on its Kafka partition. It rebuilds the apex, the metadata and the named records instead, and rare cases can be fixed by hand.

Shared names make this harder. Quicksilver stores each zone's record keys separately but keeps one metadata key shared by every zone with the same domain name, and that key lists which internal zone IDs may answer queries. During onboarding and offboarding several zone objects can briefly exist for one domain. The post also covers reading the database again between the event and the build, and combining work for the same zone in one scheduler without losing a Kafka message.

Cloudflare checked the safety claim in three ways. Equivalence tests run a full and a targeted build from the same database state and compare every key the targeted plan owns. During rollout it also ran a full build next to each targeted one. Then a mirror Zone Builder consumed the production Kafka stream, read production database state and wrote to a separate Quicksilver that served no customers. A comparer checked a 20 percent sample of zones, and the dashboard in the post shows a 0.31 percent diff rate across 234,313 matched zones, mostly timing differences. The release was staged by a hash of the zone name, free zones first and then paid zones.

A 24-hour count of build types found 86.81 percent resources only, 2.54 percent resources and metadata, 2.30 percent apex and metadata, and 1.30 percent purges. Thus 92.95 percent avoided a whole-zone rebuild, while full builds were 7.04 percent; compared with the previous 11.88 percent share, full builds fell about 40 percent. In a separate side-by-side comparison, the old production scheduler and the new mirror scheduler consumed the same events over the same 24 hours. Typical completion delays barely changed, but the largest p99 spike fell from 14.6 to 1.21 minutes. Completion delay ends when the Zone Builder writes to Quicksilver; it excludes global distribution. Aggregate working-set memory for the entire Zone Builder deployment fell from an average of 49 to 7 GiB and peaks from 79 to 12 GiB during rollout; that chart does not establish the same 24-hour window. Only after Cloudflare later shortened the per-zone rebuild interval and Kafka Aggregator buffer did median completion delay fall from about 7.7 to 3.3 seconds. That coarse-histogram chart spans almost two hours; a later fine-grained histogram over about four hours shows a median near 3.4 seconds.

These are Cloudflare measurements from distinct stages and stated windows, not a claim that all metrics came from one day or necessarily from different calendar days. The build share counts builds; deployment-wide working-set memory is not memory per build. The side-by-side delay combines all build types and customer plans, not a per-zone guarantee. Other teams can make events state changes, prove targeted output equal to full output, preserve the large-zone exception to the normal fallback, and test in a mirror before rollout.