Cloudflare DNS targeted zone builds: median delay halved, memory down 85%

Cloudflare says it has roughly halved the time it takes for a DNS change to be built and handed to its network, and cut the memory used by the system that does the work by about 85 percent. In an engineering post published on 2 November 2026, the company describes "targeted zone builds": instead of rebuilding a customer's entire DNS zone whenever something changes, the Zone Builder now works out the smallest piece it can safely rebuild, and only falls back to a full rebuild when it cannot prove a smaller one gives identical results. The figures are Cloudflare's own, measured on its production system over a 24-hour comparison.

Key points

• Cloudflare reports median build completion delay fell from about 7.7 seconds to about 3.3 seconds, roughly half.
• Average Zone Builder working-set memory fell from 49 GiB to 7 GiB (86 percent), and peaks fell from 79 GiB to 12 GiB (85 percent).
• In the 24-hour sample, 92.95 percent of builds avoided a full-zone rebuild, and full builds fell by about 40 percent, from 11.88 percent of builds to 7.04 percent.
• The largest p99 delay spike fell from 14.6 minutes to 1.21 minutes, a 12-fold reduction, according to the post.
• Cloudflare validated the change by comparing a mirror system's output against production for 234,313 zones, with a 0.31 percent difference rate, which it says was mostly timing.

What happened

Cloudflare's authoritative DNS works by turning customer zones, the records and settings that belong to a domain, into keys and values that its DNS servers can read. A component called the Zone Builder does that conversion and writes the result to Quicksilver, Cloudflare's distributed key-value store, which spreads the data across the network. The 2 November post, published on the Cloudflare blog, describes a redesign of how the Zone Builder decides what to rebuild.

The pipeline, as the post lays it out, runs like this. A change arrives through the DNS Records API or the dashboard, or another Cloudflare service changes a zone setting. The change is stored in a database, which produces a Kafka event. A DNS Kafka Aggregator combines events from several topics and passes them to the Zone Builder. The Zone Builder reads the zone data, converts it to keys, compares them with what Quicksilver already holds, and writes only the keys that changed.

The new part is the planner. It chooses one of five build types:

• Resources only: rebuilds the records at specific DNS names. Ordinary A, AAAA, TXT and CNAME changes usually take this path.
• Resources and metadata: rebuilds specific names plus shared metadata. Nameserver and wildcard changes use this path.
• Apex and metadata: rebuilds the zone apex and metadata. The post gives Universal SSL, which can change CAA records, as an example.
• Purge: removes a zone that should no longer be published.
• Full zone: rebuilds everything when a smaller job cannot be proven safe.

Two rules keep this safe, according to the post. First, a targeted build must produce keys identical to what a full build would produce; if that cannot be shown, the system does a full build. Second, uncertain events, and events that carry only a timestamp, default to full builds until the caller and purpose are identified. The planner also runs twice: once when the event arrives, and again just before execution, using a fresh read from database replicas, which can upgrade, downgrade, skip or reconstruct the build.

Cloudflare also replaced two separate schedulers, one for record-level work and one for full-zone work, with a unified scheduler. It merges pending work for the same zone, so a full build absorbs smaller jobs for that zone and a purge overrides everything. The post says Kafka's committed offset only advances once all earlier messages have finished, so a restart replays some work; the author chose repeated work over the risk of losing a change.

Background

This is the second stage of a project Cloudflare described in May 2022. In that earlier post, the company explained that its Zone Builder used to run a full build for every change: fetch every record in the zone, compare with Quicksilver, fix differences. It added a Kafka-based path for individual record changes. That post reported per-record builds about 150 times faster than full builds on average, and on a test zone of one million records, per-record builds took 6 to 8 milliseconds against about 34 seconds for a full build, the 4,250-fold difference cited in both posts. Full builds then still accounted for about 13 percent of all DNS builds, because some changes depend on the whole zone.

Since then, the load has grown. The 2026 post says the Zone Builder now receives about 700 DNS record changes per second, up from about 250 in 2022, plus around 100 other events per second such as zone setting changes. Some zones hold more than 20 million records, and the author expects them to grow toward hundreds of millions.

Quicksilver itself has also changed. Cloudflare's 2025 engineering series on Quicksilver v2 describes a move from every server storing the full dataset to a tiered caching design, with a small number of replica servers holding everything and proxies caching what they need, and reports over five billion key-value pairs totalling 1.6 TB, served at over three billion keys per second. That is the store the Zone Builder writes into.

The numbers

Cloudflare's 24-hour comparison breaks builds down like this:

Resources only86.81

Full zone7.04

Resources and metadata2.54

Apex and metadata2.30

Purge1.30

Share of DNS builds by type over 24 hours (% of builds)

	% of builds
Resources only	86.81
Full zone	7.04
Resources and metadata	2.54
Apex and metadata	2.30
Purge	1.30

Source: Cloudflare blog, How we halved DNS build delay and cut memory use by 85%

Adding the four non-full types gives 92.95 percent of builds avoiding a full-zone rebuild, matching the post. The post says full builds before the change were 11.88 percent of builds (the 7.04 percent that remain full, plus 4.84 percent of metadata builds that used to be full), so the share fell by about 40 percent. The full builds that remain average 0.35 seconds, mostly for small, new zones.

On delay, the median build completion time fell from about 7.7 seconds to about 3.3 seconds. The unified scheduler's largest p99 spike fell from 14.6 minutes to 1.21 minutes. The post is careful on the higher percentiles: an earlier, coarse histogram showed p90 falling from about 10 to 7.4 seconds, but the author says those estimates were inflated by bucket interpolation. Using a native histogram, the author reports a median around 3.4 seconds, p90 about 5.5 seconds and p99 mostly between 10 and 14 seconds. The delay measured excludes the time Quicksilver needs to distribute the data.

Average before49

Average after7

Peak before79

Peak after12

Zone Builder memory, before and after (GiB)

	GiB
Average before	49
Average after	7
Peak before	79
Peak after	12

Source: Cloudflare blog, How we halved DNS build delay and cut memory use by 85%

Kafka consumption also became steadier. Before, consumption swung between about 300 and 1,550 messages per second while production stayed around 600 to 800. After, consumption closely tracks production at about 600 to 800 messages per second.

How it was tested

The post lists three checks. Equivalence tests compared full and targeted builds from the same database state, byte for byte, for nameserver, wildcard and apex paths. A mirror environment ran a parallel Zone Builder on production events, writing to a separate Quicksilver, with a comparer sampling 20 percent of zones. The DNS Mirror Dashboard showed a 0.31 percent difference rate across 234,313 matched zones, with most differences timing-related. Rollout was gradual: the new scheduler was enabled by hashing the zone name, so zones sharing a name always used the same scheduler, with free zones first and paid zones next.

What it means

For Cloudflare customers, the visible effect is that a record edit should reach the network sooner, and that spikes, such as the 14.6-minute p99 case, are much smaller. The post says a large share of delay is the per-zone rebuild interval, not build work, and that because builds became cheaper the team shortened that interval on most plans and reduced the Kafka Aggregator's hold time. Exactly which plans changed, and by how much, is not given in the post.

For infrastructure engineers, the design lesson is the safety rule: a fast path is only allowed where it can be shown to produce the same output as the slow path, and anything uncertain goes the slow way. The memory saving is a side effect of not loading whole zones to change one record, and it matters mostly to Cloudflare's own capacity.

What we don't know yet

• Per-zone guarantees. The post says the figures combine all build types and plans, so they are not a latency guarantee for any single zone.
• The cut-off for very large zones. Above a fixed record-count threshold the system never escalates to a full build, instead rebuilding the apex, metadata and queued names. The threshold value is not given, and the post accepts that some edge cases may need manual rebuilds of individual names.
• Longer-term results. The comparison covers one 24-hour period, in Cloudflare's words a controlled one.
• Independent measurement. All figures come from Cloudflare's own telemetry; we have found no outside measurement.

What to watch next

Watch whether Cloudflare publishes the threshold for very large zones, and whether the shorter rebuild intervals reach more plans. Operators of other large DNS or configuration pipelines may want to compare the five-way planner with their own full-versus-incremental split.

Sources

• Cloudflare: How we halved DNS build delay and cut memory use by 85% (primary source, 2 November 2026)
• Cloudflare: How we improved DNS record build speed by more than 4,000x (May 2022)
• Cloudflare: Quicksilver v2, evolution of a globally distributed key-value store, part 1
• InfoQ: Cloudflare key-value store coverage