MikhbarMIKHBAR
Web

Cloudflare Cuts DNS Build Delay and Memory Usage

A new targeted build planner and scheduler have optimized Cloudflare's DNS propagation pipeline, drastically reducing memory consumption and latency for massive zones.

Cloudflare Cuts DNS Build Delay and Memory Usage

Scaling Pressures on the DNS Pipeline

Cloudflare has significantly updated its DNS propagation pipeline to handle massive growth in record updates and zone setting modifications. When the company last wrote about our DNS propagation pipeline in 2022, the Zone Builder processed approximately 250 DNS record changes every second. Today, that figure has nearly tripled to about 700 changes per second, alongside roughly 100 additional events such as zone setting changes.

While the sheer volume of events is managed by the global network, the primary challenge stems from how some of those tasks scale with zone size. Certain domains now contain more than 20 million records, with expectations that these numbers will eventually reach the hundreds of millions.

Cloudflare Cuts DNS Build Delay and Memory Usage
Image related to the report from Cloudflare Blog · Source: Cloudflare Blog

The Evolution from Full Builds to Targeted Planning

Each event triggers a build process that reads the current database state, converts it into the edge format, and writes modifications to Quicksilver. Previously, zone setting changes would routinely trigger full rebuilds of entire zones, even those containing tens of millions of records, consuming immense computational capacity and memory.

Although per-record builds were already significantly faster than full builds, targeting zone settings proved more complex. Record events clearly identify individual changes, whereas zone events can originate from multiple Cloudflare products, lack explicit context regarding why a zone shifted, and can alter shared data across multiple zones with identical names.

image7.png
Diagram of the DNS propagation pipeline: the DNS Records API, zone settings, and internal services write to databases or Kafka topics, the DNS Kafka Aggregator combines them, and the DNS Zone Builder writes to Quicksilver. · Source: Cloudflare Blog

How the New Targeted Planner Operates

To solve these challenges, engineers developed a targeted build planner alongside a new scheduler designed to combine work for identical zones. Rather than performing a full rebuild for routine updates, the system selects the smallest build it can mathematically prove is safe.

Customers typically modify DNS records via the DNS Records API or dashboard, while other services modify zone settings. These modifications generate Kafka events that are aggregated and passed to the Zone Builder for processing and distribution across the edge infrastructure.

image8.png
Diagram of Kafka messages 1 to n where a large build on message 2 blocks commits for messages 3 to n, and a pod restart replays messages 2 to n. · Source: Cloudflare Blog

Categorizing Build Types and Ensuring Safety

The updated architecture distinguishes between record keys and shared metadata keys. This distinction allows the planner to categorize work into five distinct build paths, ranging from isolated resource updates to full zone rebuilds when safety cannot be formally proven.

For instance, settings like Universal SSL may require updates to Certification Authority Authorization records at the zone apex. CAA records ensure certificate authorities issue certificates strictly in accordance with domain policies.

image12.png
Diagram of the mirror setup: the production Kafka stream feeds both the production and mirror Zone Builders, each writes to its own Quicksilver, and a comparer samples both and reports to the DNS Mirror Dashboard. · Source: Cloudflare Blog

Measurable Performance Gains

The introduction of the targeted build planner and scheduler has delivered substantial operational improvements. Full builds have been cut by 40%, and peak memory usage across the pipeline has dropped by an impressive 85%.

Furthermore, the resulting memory headroom allowed Cloudflare to safely shorten necessary resilience waits in the pipeline. This reduction has effectively halved the total delay from the moment a DNS change is initiated until its data is successfully written to Quicksilver.

Sources

Continue chronologically

Related entity coverage