Cloudflare has redesigned its DNS propagation pipeline to handle a growing stream of record and zone-setting changes more efficiently. The Zone Builder now receives about 700 DNS record changes per second, alongside roughly 100 other events, while some zones contain more than 20 million records and are expected to grow further.
The main issue was not the number of events, but the amount of work required by certain changes. Previously, a zone-setting event could trigger a full rebuild: reading every record, converting it into Quicksilver keys and comparing the result with the existing state. That approach became increasingly expensive for large zones and could require more memory than was available.
Cloudflare built a targeted build planner that selects the smallest operation it can prove is safe. A unified scheduler then combines pending work for the same zone. Depending on the change, the system can rebuild specific DNS names, update those names together with shared metadata, rebuild the zone apex and metadata, purge a zone or perform a complete zone build.
Ordinary record changes, such as updates to A, AAAA, TXT and CNAME records, generally affect only the keys for the relevant DNS names. Nameserver and wildcard changes can also affect shared metadata, while settings such as Universal SSL may require rebuilding the apex and that metadata. When the system cannot establish that a smaller operation will produce exactly the same output as a full build, it retains the full-build path.
The planner relies on more detailed events from the systems that produce zone changes. These events include changed settings and, where available, their previous and new values. Ambiguous events, missing information and updates that might affect records across the zone continue to trigger a full build rather than risk leaving stale data at the edge.
Cloudflare also had to account for domains that temporarily have multiple internal zone objects. Record keys are stored separately for each zone, while a shared metadata key identifies which same-name zones can be published. When that metadata is involved, the builder reads the current candidate list and reconstructs the key from fresh state instead of applying a patch to an older version.
Planning takes place twice because the database may change after an event is generated. Immediately before execution, the Zone Builder checks current settings, publication status for the relevant network and the latest list of same-name zone IDs. This can turn a targeted operation into a full build, change it into a purge, skip it or require the shared metadata key to be rebuilt.
The scheduler merges pending changes for a zone, adding affected names and preserving metadata requirements. A purge takes precedence over rebuild operations. Kafka acknowledgements are tracked separately from DNS work, ensuring that retries do not lose messages even when several events have been combined into one build.
To protect ordered Kafka processing, Cloudflare uses soft committing. A completed build can be recorded in memory before earlier work in the same partition finishes, but Kafka's committed offset advances only after all preceding messages are complete. If the builder restarts, those in-memory completions are replayed rather than risking the loss of a change.
For very large zones, the system avoids escalating to a full build above a fixed record-count threshold, because holding all records and existing Quicksilver keys in memory may prevent the build from finishing. Instead, it rebuilds the apex, metadata and names identified by queued events. This approach reduces the risk of one unfinishable build blocking other changes on the same Kafka partition.
Cloudflare tested targeted builds against full builds using byte-for-byte comparisons of the relevant Quicksilver keys. It also deployed a mirror Zone Builder that consumed production events and database state while writing to an isolated Quicksilver environment. A comparer checked a sample of zones for missing keys, additional keys and differing values before the new scheduler was rolled out progressively.
The resulting changes reduced full builds by 40%, cut peak memory use by 85% and halved the delay between a DNS change and its data being written to Quicksilver. During a 24-hour measurement period, 86.81% of builds were classified as resources-only operations, while 2.54% rebuilt resources together with metadata.
Sources: Cloudflare Blog.