Imagine you run a newspaper and every time someone fixes a typo in one classified ad, you reprint the entire paper. That is what Cloudflare's DNS Zone Builder used to do for zone settings changes. Record-level targeting was solved in 2022, but settings — things like enabling Universal SSL or changing nameservers — still triggered full rebuilds. On zones with 20 million records and growing, a full rebuild reads, encodes, and diffs every record while holding the entire zone in memory. The paper is about eliminating that reprint. The core claim: a targeted build planner can choose the smallest provably correct build for any zone event, and the proof obligation — not the code — was the hard part. Record events self-identify what changed. Zone setting events often don't. Some arrive as bare timestamp updates that mean 'something changed somewhere.' The planner must map each event to the exact set of DNS names and metadata keys it can affect, and when it cannot prove the scope is bounded, it falls back to a full build. The rule is byte-for-byte equivalence: every key a targeted build writes must be identical to what a full build would produce. The architecture is a five-tier build taxonomy — resources-only, resources-plus-metadata, apex-plus-metadata, purge, and full — fed by an event enrichment step where producers now include changed fields and previous/new values. Each setting is traced through the code that generates DNS output and classified by what it can affect. Unknown events, missing details, and ambiguous timestamp-only updates always escalate to full builds. The planner never converts uncertainty into less work. A subtle complication: one domain name can map to multiple Cloudflare zone objects during onboarding and offboarding. A shared metadata key in Quicksilver acts as a directory listing which zone IDs are published for a given name. Record-only changes skip this key entirely. Nameserver and wildcard changes must rebuild it from a fresh snapshot, because patching a stale copy risks serving incorrect authority data. The Zone Builder writes the triggering zone's records before updating the metadata that references them. The scheduling layer deserves attention. Events are planned twice: once at arrival to create a conservative work list, and again immediately before execution against a fresh database snapshot. Between those two moments, the database can change — other events may arrive, zones may be created or deleted. This two-phase approach means the planner never acts on stale state. A new scheduler combines queued work for the same zone, so five rapid-fire changes produce one build, not five. The results on production: peak memory dropped 85%, because the builder no longer holds 20M+ record zones in memory for settings changes. The freed headroom allowed Cloudflare to shorten resilience waits that the pipeline had always used as buffers, cutting end-to-end propagation delay — from DNS change to data written to Quicksilver — by half. Throughput rose from 250 events/sec in 2022 to 700 record changes plus 100 zone events per second today. The one honest tradeoff: for zones above a fixed record-count threshold, the builder never escalates to a full build at all, because a full build cannot finish — it retries indefinitely and blocks its Kafka partition. Instead it rebuilds the apex, metadata, and every name identified by queued events. This is not provably complete for all edge cases, and Cloudflare mitigates with zone holds (preventing the same name from being added to another account) and manual per-name rebuilds for rare operations like enabling a zone on another network.
