Cloudflare makes DNS changes faster by rebuilding less
Targeted zone builds cut preparation time and memory use. The reported gains describe Cloudflare’s control pipeline, not a shortcut around resolver caches.
Cloudflare says it has roughly halved the time taken to prepare DNS changes for its distribution system by avoiding unnecessary rebuilds of enormous zones. Its engineering account reports a fall in median build-completion delay from about 7.7 seconds to 3.3 seconds, alongside an 85% reduction in peak working memory. These are measurements of the update pipeline—not a promise that every DNS lookup or cached answer becomes twice as fast.
That boundary is the story. A DNS provider has to turn a customer’s configuration change into data its authoritative servers can serve. Speeding up that preparation helps changes become ready sooner, but it does not retroactively change the lifetime of answers already cached elsewhere.
Small edits were triggering large jobs
A DNS zone contains the records and settings associated with a domain. Cloudflare’s Zone Builder reads the relevant database state, converts it into the form its serving infrastructure expects and writes changed keys to Quicksilver, its distributed storage system.
The old full-build path was simple: read all the records, derive the desired state and compare it with the stored state. Even when only a few output keys changed, the process still read and transformed the entire zone. That becomes expensive when some zones contain more than 20 million records.
The new planner tries to identify the smallest set of work that remains correct. An ordinary address-record change may require rebuilding just one DNS name. A change affecting nameservers, wildcards or shared metadata needs a broader operation. A newly published zone can still require a full build. The optimization depends on understanding the consequences of an event, not merely skipping records because the zone is large.
Correctness is the difficult part
Several internal zone objects can temporarily share the same public domain during lifecycle changes. Their records and shared metadata have to agree about which data may be served. A targeted update that writes fewer keys but leaves the wrong directory of published zones would be fast and incorrect.
Cloudflare therefore describes planning from the event and checking fresh state again before execution. Unknown or insufficiently described changes generally retain a full rebuild. There is a documented exception for zones too large to fit a full build in memory: those use targeted work with additional operational safeguards, rather than repeatedly attempting a job that cannot finish.
The company tested equivalence against full builds and used a mirror pipeline consuming production events while writing to separate storage. Its comparison sampled 20% of zones, distinguishing persistent differences from temporary mismatches caused by the two pipelines finishing at different times.
The gain creates room to shorten waiting
In a 24-hour measurement, 92.95% of builds avoided rebuilding the complete zone. Peak working memory fell from 79 GiB to 12 GiB. With less expensive work and better handling of database replica lag, Cloudflare could shorten protective waiting intervals as well as the builds themselves.
The reported median therefore reflects a combination of narrower work and reduced waits. Cloudflare also notes that coarse histogram buckets made some percentile estimates imprecise; the headline numbers should not become a service guarantee for an individual zone.
For operators, the useful improvement is fewer small changes waiting behind disproportionately large jobs. For everyone else, this is a reminder that internet responsiveness sometimes improves through bookkeeping: knowing exactly which records must change can matter more than adding another machine to reread all the records that did not.
