TL;DR
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Cloudflare says it has changed its DNS build pipeline so zone-setting changes can trigger smaller, targeted builds rather than rebuilding entire zones. The company reports an 85% reduction in peak memory use and a halving of the time from a DNS change to its data being written to Quicksilver; performance figures and implementation details come from Cloudflare’s own report.
Cloudflare says it has halved the time between a DNS change and the change being written to Quicksilver, its distributed key-value store, while cutting peak memory use in its DNS build pipeline by 85%. The company attributes the reported gains to a planner that selects smaller, targeted builds and a scheduler that combines work for the same DNS zone.
Cloudflare’s Zone Builder processes changes to DNS records and zone settings, turns the current zone data into a format used by the company’s authoritative DNS servers, and writes resulting changes to Quicksilver. Cloudflare says the system now receives about 700 DNS record changes per second, compared with about 250 when it described the pipeline in 2022, as well as roughly 100 other events such as zone-setting changes. Those are company-reported rates, not an independently audited measurement.
The earlier approach could rebuild a zone whenever it received a change, even if only one setting needed to be reflected. A full build reads and processes every record in the zone, compares the result with what is already stored, and then writes changed data. Cloudflare says some zones now contain more than 20 million records, making the work and memory required for a full build increasingly difficult to scale.
The new planner aims to identify the smallest build that Cloudflare can establish is safe. The scheduler combines work for the same zone. According to the company, zone-setting changes no longer trigger full rebuilds of zones with tens of millions of records. The reduction in memory use also gave Cloudflare room to shorten waits in the pipeline that it says were needed for resilience, contributing to the reported halving of the write delay.
Faster Updates With Less Build Capacity
DNS changes must be processed before Cloudflare’s authoritative servers can serve the updated data. Reducing the time taken by the build stage can shorten the interval between a customer or internal service making a change and that change reaching the network. Cloudflare’s reported reduction therefore concerns a central part of the propagation pipeline, rather than a change to DNS itself.
The memory reduction also matters as zones grow. If a build must hold and process an entire zone, very large zones can demand substantial resources or exceed the memory available to a worker. Targeting only data affected by a change can reduce repeated work and leave more capacity for the pipeline’s other tasks. Cloudflare says it expects some zones to grow toward hundreds of millions of records, though it did not provide a date or a forecast for when that might occur.
The reported results do not establish how much faster every DNS change will reach every user. The stated measure is the time until the data is written to Quicksilver; the supplied report does not give a separate end-to-end measurement for propagation across all of Cloudflare’s network or for DNS lookup performance.
Popular right now
De'Longhi Rivelia Fully Automatic Espresso Machine with Milk Frother, White
TCL 65-Inch QM6K QLED Mini-LED 4K HDR Smart Google TV, 144Hz
KitchenAid Artisan 5-Quart Tilt-Head Stand Mixer, Almond Cream
As an affiliate, we earn on qualifying purchases.
From Full Zone Builds to Targeted Work
In its 2022 account of the pipeline, Cloudflare said per-record builds were, on average, 150 times faster than full builds. On a test zone with one million records, the company said per-record builds were 4,250 times faster. It identified zone-setting changes as the next area for applying targeted builds. These comparisons describe Cloudflare’s earlier measurements and do not quantify the current system’s performance for all changes.
Targeting settings proved more complicated than targeting an individual DNS record. A setting can affect output such as records at the zone apex, while some data may be shared by zones with the same name. The system must determine what names may change, whether shared metadata or the published-zone list is affected, and what old data must be removed. A build that does too much wastes resources; one that does too little risks leaving incorrect or stale DNS data at the edge.
Cloudflare says it updated event producers to include which zone fields or settings changed, along with previous and new values when available. But some events only indicate that a timestamp changed, without explaining why. In those cases, the company says the planner still performs a full build until it can establish whether the event could affect DNS output elsewhere in the zone.
“The number of events was never the real problem. The problem was the kind of work some of those events needed, and how that work grows with the size of a zone.”
— Cloudflare, in its blog report
Performance Measures and Safety Limits
The supplied report does not state the absolute delay before or after the change, the measurement period, or whether the halving applies to an average, a peak, or a particular class of DNS updates. It also does not describe an independent evaluation of the 85% peak-memory reduction. The figures should be read as Cloudflare’s account of its internal system.
It is not clear how the gains vary by zone size or by the type of setting changed, nor how often ambiguous events still require a full build. Cloudflare says timestamp-only updates, missing details, unknown events, and changes that may affect records across a zone continue to receive broader treatment. The supplied portion of the report does not give a complete account of every planner rule or all safeguards used to handle database updates and Kafka messages.
More Settings May Become Targetable
Cloudflare’s report describes the targeted planner and scheduler as a change to its existing DNS propagation pipeline. It does not announce a separate rollout schedule or a future performance milestone. The next practical step described in the report is continued work to identify what less-specific events mean, so the system can distinguish harmless bookkeeping from changes that require rebuilding more DNS data.
Until those event sources can be identified with confidence, Cloudflare says it will retain full builds for uncertain cases. That approach limits the risk of leaving stale or incorrect data in Quicksilver, while leaving room for further reductions in build work if more events can safely be classified.
Key Questions
What did Cloudflare change?
Cloudflare says it added a planner that chooses targeted DNS builds and a scheduler that combines work for the same zone. The changes are intended to avoid rebuilding an entire zone when a smaller build can safely reflect an update.
What does the 85% memory reduction refer to?
It refers to a reduction in peak memory use in the DNS build pipeline, according to Cloudflare. The supplied report does not give the measurement period or a detailed before-and-after memory figure.
Does this mean all DNS changes now propagate twice as fast?
No such claim is established by the supplied information. Cloudflare says it halved the time from a DNS change until its data is written to Quicksilver. That is a pipeline measure, not a stated guarantee of end-to-end propagation time for every change or user.
Why do some updates still trigger a full build?
Some events do not identify what changed or whether a change could affect data across a zone. Cloudflare says it retains full builds for ambiguous, incomplete, or unknown events rather than risk producing stale or incorrect DNS data.
How many changes does the Zone Builder handle?
Cloudflare says it receives about 700 DNS record changes per second, up from about 250 in its 2022 account, plus roughly 100 other events such as zone-setting changes. These figures are Cloudflare’s reported rates.
Source: blog.cloudflare.com
