Cloudflare has changed how its DNS Zone Builder processes updates, replacing many complete-zone rebuilds with smaller, targeted jobs. The company says the change reduced peak working-set memory for the service by 85% and cut its largest observed 99th-percentile build delay from 14.6 minutes to 1.21 minutes.
The Zone Builder turns DNS records and zone settings into data for Cloudflare’s authoritative DNS servers. It writes that output to Quicksilver, the distributed key-value store used to propagate changes across the company’s network. The reported build delay measures the time until data is written to Quicksilver; it does not include Quicksilver’s subsequent distribution across the network.
Why full builds became a problem
Cloudflare says the Zone Builder now receives about 700 DNS record changes per second, up from roughly 250 in 2022, as well as about 100 other events, including changes to zone settings. The greater challenge, according to the company, is the size of some zones: the largest contain more than 20 million records, and Cloudflare expects them to grow further.
A traditional full build reads the zone’s current settings and every DNS record, converts them into the format used at the edge, compares the resulting keys with those in Quicksilver, and removes or updates keys as needed. Although the final write includes only changed data, the process still has to read and process the entire zone. That becomes costly in memory and time as zones grow.
Record-level updates had already been optimized to rebuild only affected names. The harder task was safely applying the same idea to settings changes. A setting can affect records at the domain apex, shared metadata, or potentially output across the whole zone. Events may also lack enough detail to identify their effects. Doing too little risks leaving stale or incorrect DNS data; doing too much wastes resources.
A planner chooses the smallest safe job
Cloudflare added a targeted build planner and a unified scheduler. The planner classifies work into five types: rebuilding specified DNS names; rebuilding names plus shared metadata; rebuilding the apex and metadata; purging a zone that should no longer be published; or rebuilding the full zone. The core safety rule is that targeted output must match what a full build would produce, byte for byte. When the system cannot establish that, it retains the full-build path.
To improve event detail, Cloudflare changed producers to include which zone fields or settings changed and, where available, their previous and new values. Unknown events and updates that cannot be reliably interpreted still trigger full builds. This conservative fallback is important because a zone setting can affect more than the record named in an event.
Some metadata is shared across Cloudflare zone objects with the same domain name. The system therefore checks the current set of zones before writing shared metadata, and writes the triggering zone’s records before metadata that refers to them. It also rereads current publication state immediately before execution. That fresh check can change a planned job into a full build or purge, skip work that is no longer needed, or reconstruct shared metadata from the current candidate zones.
There is a practical limit: full builds for the largest zones may not fit in memory or finish successfully. Above a fixed record-count threshold, the builder instead updates the apex, metadata, and names identified by queued events rather than escalating to a full-zone rebuild. Cloudflare says rare cases that require broader work can be handled by manually rebuilding individual names.
Scheduling, validation and measured results
The unified scheduler combines queued work for the same zone. For example, a regular record update and a wildcard change can become one job covering both names and the required metadata. A full-build requirement takes precedence over narrower work, while a purge overrides rebuilds. The scheduler keeps the work plan separate from the Kafka messages awaiting acknowledgment, preserving those messages through retries.
That accounting matters because Kafka advances a partition’s committed position only after earlier messages are complete. A slow build can otherwise hold up acknowledgment of later events, and moving the offset past unfinished work could lose a change after a restart. Cloudflare says targeted work reduced long-running builds that could block this progress.
Before rollout, the company tested targeted output against full builds and ran a mirror Zone Builder on the production Kafka stream and database state, but writing to a separate Quicksilver environment. A comparer sampled 20% of zones for missing keys, extra keys and value differences. Cloudflare rolled out the scheduler by a hash of zone name so zones sharing a name would remain on the same scheduler and avoid competing writes to shared metadata.
Across a 24-hour measurement, 92.95% of builds avoided rebuilding the complete zone: 86.81% were resources-only, 2.54% rebuilt resources and metadata, 2.30% rebuilt the apex and metadata, and 1.30% were purges. Full builds accounted for 7.04%. Cloudflare says the two metadata build types had previously required full builds, and that full builds fell by about 40% when those changes are included in the comparison.
In a side-by-side comparison of production and mirror over the same events, the largest p99 build-completion delay dropped from 14.6 minutes to 1.21 minutes. Average working-set memory declined from 49 GiB to 7 GiB, while peak usage fell from 79 GiB to 12 GiB. Cloudflare says the reduced load also let it shorten resilience-related waits in the pipeline, helping halve the time from a DNS change to its data being written to Quicksilver.