原文標題：How we halved DNS build delay and cut memory use by 85%
Cloudflare 11 月 2 日說明其權威 DNS 資料更新管線的改造。Zone Builder 目前每秒處理約 700 筆 DNS 紀錄變更，另有約 100 筆區域設定等事件；相較 2022 年每秒約 250 筆紀錄變更，負載已大幅成長。更關鍵的問題是部分 DNS zone 超過 2,000 萬筆紀錄，舊設計遇到區域設定更新時，即使只有少數輸出鍵值會改變，仍需讀取、轉換與比較整個 zone。
新流程由 DNS Records API、控制台或內部服務寫入資料庫，產生 Kafka 事件，經 DNS Kafka Aggregator 匯入 Zone Builder，再轉成供權威 DNS 使用的 Quicksilver 鍵值。Cloudflare 將事件生產端改為攜帶設定欄位及新舊值，讓 targeted build planner 判斷變更範圍，並以統一 scheduler 合併同一 zone 的待辦工作。
規劃器分成五種作業：僅重建特定 DNS 名稱資源、資源與共用中繼資料、zone apex 與中繼資料、移除不再發布的 zone，以及完整重建。一般 A、AAAA、TXT、CNAME 紀錄通常只需更新指定名稱；nameserver 或 wildcard 變更須連同中繼資料更新；Universal SSL 相關設定則可能涉及 apex 的 CAA 紀錄。對於缺少足夠變更資訊或無法證明局部重建等價的事件，仍維持完整重建。
系統也必須處理同名 zone 在不同帳戶或生命週期階段共存的情況。Quicksilver 以各 zone 的紀錄鍵與同名 zone 共用的中繼資料鍵表示狀態；Zone Builder 在實際寫入前重新讀取發布快照，避免以過期事件覆寫最新設定。資料庫複本落後時會拒絕讀取；Kafka 透過 soft committing 允許作業先後完成不同步，但只有較早事件完成後才推進提交位置，以避免重啟時漏掉變更。
Cloudflare 以完整建置與局部建置的逐鍵等價測試驗證正確性，並建立 mirror Zone Builder，讀取正式 Kafka 與資料庫，寫入不承載客戶流量的獨立 Quicksilver。比較器抽樣 20% zone 檢查缺少、額外或值不同的鍵，之後依 zone 名稱雜湊分批推出，避免同名 zone 分散至兩種排程器。
在 24 小時量測中，86.81% 作業只重建資源、2.54% 更新資源及中繼資料、2.30% 更新 apex 與中繼資料、1.30% 為 purge，合計 92.95% 不需全區重建，完整建置占 7.04%，整體全區重建次數約減少 40%。平均工作記憶體從 49 GiB 降至 7 GiB（約 86%），尖峰從 79 GiB 降至 12 GiB（85%）；p99 最嚴重延遲尖峰由 14.6 分鐘降至 1.21 分鐘。
縮短每個 zone 的重建間隔與 Kafka Aggregator 等待資料庫複本追上的緩衝後，變更到寫入 Quicksilver 的中位延遲從約 7.7 秒降至 3.3 秒。新 native histogram 顯示 p90 約 5.5 秒、p99 約 12 秒。這些數值不包含 Quicksilver 在全球網路的後續散布時間，也不是個別客戶 zone 的延遲保證。
發生了什麼事
Cloudflare 以五類安全建置策略及統一排程器，取代區域設定變更就全區掃描的舊做法，並完成正式環境漸進推出。
為什麼重要
DNS 大型 zone 的全區重建會消耗大量記憶體，還可能阻塞 Kafka partition 的其他變更；新設計同時降低資源需求與尾端延遲。
影響哪些人
受影響的是使用 Cloudflare 權威 DNS 的網站與企業，以及維運其全球 DNS 資料發布管線的工程團隊；官方未要求客戶修改設定。
已確認與未確認
官方提供 24 小時比較數據與 mirror 驗證方法，但未公開所有 zone 類型的獨立延遲，也明確指出 Quicksilver 全球散布時間不在本次統計內。
