Cloudflare has announced a major architectural overhaul of its DNS propagation pipeline, successfully slashing peak memory usage by 85% and cutting the time required to push changes to its global edge network in half. The upgrades directly address the growing scale of internet infrastructure, particularly massive enterprise zones containing upwards of 20 million individual DNS records.
When Cloudflare last detailed its DNS propagation pipeline in 2022, its internal "Zone Builder" service processed approximately 250 DNS record changes per second. Today, that volume has nearly tripled to roughly 700 record changes per second, alongside an additional 100 events tracking zone setting modifications and administrative updates. However, engineers discovered that raw event volume was never the true bottleneck. Instead, the real challenge lay in the computational complexity of the work triggered by certain events and how that workload scaled with the size of the zone.
Every modification to a domain—whether altering an individual record or updating universal SSL settings—starts a clock measuring how long it takes to transform that change into data usable by Cloudflare’s authoritative DNS servers. This process, known as a "build," reads the current database state, converts it into an edge-optimized format, and writes the output to Quicksilver, Cloudflare’s globally distributed configuration store.
Historically, the Zone Builder relied heavily on full builds, which required reading, encoding, and comparing every single record within a zone while holding the entire dataset in memory. While efficient for small domains, this approach buckled under the weight of massive zones holding tens of millions of records that could no longer fit comfortably into available memory. Furthermore, while per-record updates could be targeted efficiently, zone-wide setting changes—such as enabling Universal SSL, which can alter Certification Authority Authorization (CAA) records at a domain’s bare apex—historically forced the system to execute a costly, full-zone rebuild.
To solve this scaling limitation without sacrificing reliability, Cloudflare’s engineering team set out to answer a critical operational question: how to safely execute targeted builds for zone settings without inadvertently leaving stale or incorrect DNS data at the edge.
Because zone events can originate from a wide array of internal products, often without explicitly detailing the exact nature of the modification, building a targeted system required extreme caution. Choosing too little work could result in outdated DNS records, while performing too much work would waste precious computational capacity.
To bridge this gap, Cloudflare developed a targeted build planner capable of determining the smallest possible build that could be mathematically proven safe, paired with a newly unified scheduler designed to intelligently combine multiple pending updates for the same zone. By ensuring that zone setting modifications no longer triggered full rebuilds on domains with tens of millions of records, the new architecture achieved dramatic efficiency gains.
The immediate result was an 85% reduction in peak working-set memory, dropping aggregate active memory consumption from an average of 49 gigabytes down to just 7 gigabytes, with peak usage falling from 79 gigabytes to 12 gigabytes. This newly recovered system headroom allowed engineers to safely shorten internal pipeline resilience delays, ultimately cutting the median time from a DNS change to its final write in Quicksilver by half.
The pipeline architecture relies on a multi-stage flow where DNS APIs, zone settings, and internal services write to databases and Kafka topics. A DNS Kafka Aggregator then combines these streams before the Zone Builder compiles the final output and writes it to Quicksilver.
To maintain strict data integrity, the system incorporates rigorous verification steps. Because events describe historical actions that occurred in the past, builds often experience brief queues while waiting for database states to settle. To prevent inconsistencies, the Zone Builder plans work conservatively based on the initial event, but immediately before execution, it reads a fresh publication snapshot from read-only database replicas. This ensures that current zone settings, network publication statuses, and same-name zone identification keys are fully up to date before any data is written to the edge.
The transition to the unified scheduler also resolved long-standing Kafka processing bottlenecks. Previously, slow full builds on large zones could block partition offsets, creating backlog spikes where consumer rates lagged significantly behind production event generation. With targeted builds handling the vast majority of updates—accounting for more than 92% of all daily builds—the system now processes Kafka events smoothly and continuously at the rate they arrive, eliminating previous throughput spikes that once reached up to 1,550 messages per second.
To ensure absolute safety during rollout, Cloudflare deployed a comprehensive testing and mirroring methodology. Every new release runs through a mirror Zone Builder that consumes live production Kafka streams and reads live database states, but writes exclusively to an isolated Quicksilver environment that serves no live customer traffic. A custom-built automated comparer samples 20% of active zones across both environments, continuously monitoring for missing keys, extraneous entries, or value discrepancies.
Reflecting on the evolution of the pipeline, engineers noted that while complete elimination of full builds was initially a theoretical goal, operational reality proved that full builds remain necessary and efficient for specific scenarios. Zones being published for the first time, or changes affecting records scattered across an entire domain, still require full-zone compilation. However, because those full builds are now largely restricted to small, newly created domains, their overall computational impact has plummeted.
By fundamentally rethinking how zone events are planned, scheduled, and verified, Cloudflare has successfully future-proofed its DNS propagation infrastructure, ensuring it can seamlessly handle the continuous growth of massive enterprise domains while delivering faster, more reliable updates across its global network.
