Cloudflare's largest DNS zones no longer get full rebuilds: they don't fit in memory

Cloudflare has stopped running full rebuilds on its largest DNS zones, because a complete build of those zones cannot finish, the company said in an engineering post on November 2, 2026. The change came with a new planner and scheduler that cut the Zone Builder's peak memory by 85% and halved the median wait before a DNS edit reaches its data store.

The headline numbers are about speed. The more unusual part is the tradeoff: above a fixed record count, the system's old fallback no longer exists.

Why a full build became impossible

The Zone Builder turns DNS changes into data for Cloudflare's authoritative servers. A full build reads every record in a zone and holds them, along with every existing key in its Quicksilver store, in memory at once. The biggest zones already exceed 20 million records, and Cloudflare is planning for hundreds of millions.

For those zones, the post says, the data does not fit. Worse, each failed attempt blocks the queue it sits in, so one giant zone can delay unrelated customers sharing that Kafka partition.

So the builder now refuses to escalate past that size. It rebuilds the zone apex, the shared metadata and each name named by the queued events. In the few situations this misses, such as turning on a zone in a separate network, staff can rebuild single names by hand.

The rule that replaced it

For every other zone, the design rule is strict. Each key written by a targeted build has to match, byte for byte, what a full build would have written. If the planner cannot prove that, it falls back to a full build, and it never turns uncertainty into less work.

Cloudflare tested this by running a mirror builder on the production event stream, writing to an environment that serves no customers. A comparison tool then sampled one zone in five, looking for keys that were absent, surplus or changed.

What the numbers show

Traffic to the pipeline has nearly tripled since 2022, from about 250 record changes per second to about 700. Over a 24-hour measurement, 92.95% of builds avoided rebuilding a complete zone. The 7.04% that remained averaged 0.35 seconds, since they mostly hit new zones with few records.

Average memory across the deployment went from 49 GiB to 7 GiB, and peak use from 79 GiB down to 12 GiB. In a side-by-side run, the worst p99 spike in build delay shrank from 14.6 minutes to 1.21. The median delay fell only after a later step, when the extra headroom let engineers shorten two deliberate waits, moving it from roughly 7.7 seconds to roughly 3.3.

Those delay figures stop at the write to Quicksilver. They exclude the time data takes to spread across Cloudflare's network, and the company says they are not a latency guarantee for any individual zone.