Cloudflare targets DNS builds, cutting Zone Builder memory and delays

Cloudflare changed its DNS Zone Builder to choose the smallest safe build for each change instead of rebuilding whole zones, cutting peak memory by 85% and halving median build completion delay. The planner and a unified scheduler also let 92.95% of builds avoid rebuilding the complete zone.

Why full builds became costly

The Zone Builder turns database changes into data for Cloudflare's authoritative DNS servers and writes changes to Quicksilver. A full build reads, encodes, and compares every record and holds the whole zone in memory, which is costly for zones with tens of millions of records. Today the builder receives about 700 DNS record changes per second, up from about 250 in 2022, plus about 100 other events.

Targeted builds and five build types

Events now include changed zone fields and settings where available. The planner maps each change to one of five build types: resources only; resources and metadata; apex and metadata; purge; or full zone. It uses full builds only when smaller work cannot be proven safe. Over 24 hours, 86.81% were resources only, 2.54% resources and metadata, 2.30% apex and metadata, 1.30% purge, and 7.04% full zone. The two metadata types were previously full builds, so full builds fell by about 40%.

Shared names and scheduling

Quicksilver stores one metadata key shared by every Cloudflare zone with the same domain name. Targeted builds rebuild that key from the current candidate set when needed and write a zone's records before metadata that refers to them. A unified scheduler merges queued work for the same zone, so an A record change and a wildcard change can become one build. It keeps Kafka messages attached until results are safely written, and it prevents one busy zone from taking every worker through a per-zone rebuild interval.

Validation, memory and delay results

Equivalence tests compare full and targeted builds byte for byte. A mirror Zone Builder consumes production Kafka events and reads production database state while writing to a separate Quicksilver environment; a comparer checks a 20% sample. After rollout, aggregate working-set memory fell from an average of 49 GiB to 7 GiB and peaks from 79 GiB to 12 GiB. In a side-by-side comparison, the largest p99 delay spike fell from 14.6 minutes to 1.21 minutes. After shorter aggregator and rebuild-interval waits, median build completion delay fell from about 7.7 seconds to about 3.3 seconds.

Sources: Cloudflare