Cloudflare stops rebuilding entire DNS zones over a single setting: 85% less memory and half the delay

On November 2, 2026, Cloudflare published a technical deep dive on how it redesigned the system that turns every DNS change into data its authoritative servers can serve. The results, according to its own measurements: the system's peak memory dropped 85% (from 79 to 12 GiB), full zone builds fell by about 40%, and the median delay between you changing a record or a zone setting and that change being written to its internal store was cut by more than half, from roughly 7.7 to roughly 3.3 seconds. This is not a new product and there is nothing to configure: it is an engineering change on Cloudflare's side. But if your domains live there, your DNS is what moves through that pipeline, and the post leaves several useful lessons for anyone designing a system that has to rebuild state from events.

The problem: rebuilding everything over one setting

Cloudflare explains that its Zone Builder now receives about 700 DNS record changes per second, almost triple the 2022 figure, plus about 100 events of other kinds, such as zone setting changes. Some zones already have more than 20 million records, and the company expects them to grow into the hundreds of millions.

The pipeline, simplified, goes like this: the change is saved in a database, generates an event in Kafka, an aggregator collects events from several topics and hands them to the Zone Builder, which reads the zone's data, converts it into keys the authoritative servers understand, and writes only what changed to Quicksilver, the distributed key-value store that spreads configuration across the whole network.

Back in 2022, Cloudflare had already solved the easy part: per-record builds, which on average were 150 times faster than rebuilding the whole zone. What was left were zone settings. A setting like Universal SSL can change the apex's CAA records (the bare domain, like example.com) and the zone's metadata. Since a zone event can come from many products and doesn't always say what changed, the system played it safe: read, encode and compare every record in the zone, with the entire zone in memory. For small zones, cheap. For zones with tens of millions of records, per Cloudflare itself, the zone doesn't even fit in memory.

The solution: a planner that picks the smallest build that is safe

The centerpiece is a targeted-build planner. First, they changed the event producer so it includes which fields and settings changed, with their old and new values when they exist. Then they traced each setting through the code that generates the DNS output to classify what it can affect.

With that, the planner chooses among five build types:

Records only: rebuilds the affected DNS names without touching metadata. This is the normal path for A, AAAA, TXT and CNAME changes.
Records and metadata: for nameserver and wildcard changes.
Apex and metadata: for settings like Universal SSL.
Purge: removes a zone that should no longer be published.
Full zone: when it can't be proven that something smaller is safe.

Cloudflare's rule is strict: every key a targeted build writes has to be identical, byte for byte, to the one a full build would write. If they can't prove it, a full build runs. In their words, the planner "never turns uncertainty into less work."

There is one deliberate exception: above a certain number of records, the system never escalates to a full build, because those zones don't fit in memory, the build never finishes, and while it retries it blocks all the other changes in its Kafka partition. In those cases it rebuilds the apex, the metadata and the names the events point to. Cloudflare acknowledges this is a tradeoff and that for the rare cases left over, it can rebuild names by hand.

Infographic with the figures for Cloudflare's Zone Builder before and after the planner: memory, delay and breakdown by build type

The details that make it reliable

What's interesting about the post isn't "we made it faster" but how they avoided leaving stale or incorrect DNS data at the edge:

One zone, several internal owners. During sign-ups, removals and other lifecycle changes, several internal zones with the same domain name can briefly exist. A shared metadata key says which ones are published. When a build touches it, it rebuilds it in full from a fresh read instead of patching an old copy, and it writes the records before the metadata that points to them.
Planning twice. The event generates a conservative plan, but right before executing, the Zone Builder re-reads the state: a targeted build can become a full one, one can turn into a purge, or one can be skipped. That read comes from read-only replicas, and since Kafka and replication run at different speeds, the aggregator delays events long enough and the database rejects the read if the replica is lagging.
A single scheduler. Before, there were two (one for records and another for full zones) that couldn't combine work with each other. The new unified scheduler batches events for the same zone that arrive before the build starts. Batching can only add work: if one event asks for a full zone, everything becomes a full zone.
No lost messages. They use soft committing, which they had already described: a build can finish out of order, but the Kafka offset only advances when everything before it has finished. If the process restarts, work gets repeated instead of a change getting lost.

To ship it, they ran equivalence tests (full build versus targeted, compared byte for byte), ran a full build alongside each targeted one during the rollout, and set up a mirror Zone Builder that consumes the production Kafka and writes to a separate Quicksilver that serves no traffic. A comparator checks a 20% sample of zones; in the capture they publish, the difference rate was 0.31% over 234,313 zones, which Cloudflare mostly attributes to timing gaps between the two systems. The rollout went by hash of the zone name, first on free zones and then on paid ones.

The numbers

In a 24-hour measurement, according to Cloudflare:

Build type	Percentage
Records only	86.81%
Full zone	7.04%
Records and metadata	2.54%
Apex and metadata	2.30%
Purge	1.30%

The two types involving metadata used to be full builds; that's where the roughly 40% drop in full builds comes from. The ones that remain last 0.35 seconds on average because, per the post, they are mostly triggered by new, small zones.

Other reported results:

Memory: the average dropped from 49 to 7 GiB (86%) and the peak from 79 to 12 GiB (85%).
Worst tail: comparing production against the mirror over the same 24 hours, the highest p99 peak dropped from 14.6 to 1.21 minutes.
Median delay: with memory freed up, they dared to shorten the interval between rebuilds of the same zone on most plans and the time the aggregator holds events. The median went from about 7.7 to about 3.3 seconds. With a native Prometheus histogram, they now report a p90 of about 5.5 seconds and a p99 of about 12.
Kafka: they now consume at the rate events arrive, instead of falling behind and catching up in bursts of up to 1,550 messages per second.

What it doesn't say

You have to read carefully what was measured. The delay runs from the change until the Zone Builder finishes writing to Quicksilver. Cloudflare clarifies that it doesn't include Quicksilver's distribution across its network, which varies by location and which this work didn't touch. It also warns that the figures combine all build types and plans, so they "are not a latency guarantee" for any particular zone. There are also no per-plan figures: the post only says that the interval between rebuilds depends on the plan and that it was shortened "on most."

And something they correct about themselves: in 2022 they said they planned to eliminate full builds. Now they say that isn't realistic or useful, because a zone being published for the first time needs to write everything.

My take

For anyone with domains on Cloudflare, the practical effect should be subtle: DNS and zone setting changes reaching the edge a bit sooner and fewer odd multi-minute spikes. There's nothing to do on your end.

The value is in the method, and it applies to any system that rebuilds state from events: a bot that recalculates catalogs, a CMS that regenerates caches, a billing pipeline. My read is that there are three ideas to take home. First, have events say what changed; without that, the only safe path is rebuilding everything. Second, when in doubt, more work and never less. And third, the acid test wasn't a benchmark, but a mirror system with real traffic comparing its output against production before letting it loose. That discipline is what separates an optimization from an incident.