Cloudflare 改寫 DNS 建置流程：改一筆紀錄的等待從 7.7 秒變 3.3 秒，記憶體尖峰少 85%

一句話看懂：Cloudflare 把 DNS 變更的處理方式從「每次重抄整本通訊錄」改成「只改有變的那幾頁」，等待時間砍半，記憶體用量少了 85%。

先用白話講：DNS 建置是什麼？

DNS 就像網路的通訊錄：你輸入網址，DNS 告訴電腦這個網址對應到哪台伺服器。

你在 Cloudflare 後台改一筆 DNS 紀錄時，這筆修改不會直接送到全球機房。中間要先經過一個叫 Zone Builder 的程式，把資料庫裡的紀錄「翻譯」成全球 DNS 伺服器看得懂的格式，這個步驟叫做建置（build）。

問題出在：以前只要改到網域層級的設定，Zone Builder 常常得把整個網域的紀錄全部重新讀一遍。小網站沒感覺，但有些網域有超過 2,000 萬筆紀錄，等於為了改一頁，把整本通訊錄重抄一次。

發生什麼事

Cloudflare 在 11 月 2 日的官方部落格公開了這次改版：

• 現在 Zone Builder 每秒大約收到 700 筆 DNS 紀錄變更（2022 年約 250 筆）
• 新增一個「建置規劃器」，判斷這次修改最少要重建哪些部分；新增統一排程器，把同一個網域短時間內的多筆修改合併成一次
• 24 小時統計：92.95% 的建置不必重建整個網域，只有 7.04% 還是完整重建

改善有多大？

要注意：這些數字只算到「寫進 Quicksilver（Cloudflare 自家的分散式設定資料庫）」為止，不含傳到全球機房的時間，也不是單一網域的保證值。

給開發者的技術細節

• 五種建置類型：只重建特定名稱、名稱加共用中繼資料、網域根（apex）加中繼資料、移除網域、完整重建。一般的 A、AAAA、TXT、CNAME 修改大多走第一種
• 安全原則：小範圍建置寫出的每個鍵，都必須跟完整重建「位元組完全相同」；證明不了就退回完整重建。事件沒說清楚改了什麼，也一律完整重建
• 上線前驗證：另外架一套鏡像 Zone Builder 吃正式環境的 Kafka 事件，寫到不服務客戶的 Quicksilver，抽 20% 的網域比對兩邊結果
• Kafka 不漏訊息：建置可以亂序完成，但提交的位置只會在前面所有訊息都完成後才往前推；寧可重做，也不要弄丟一筆修改

我的看法

對一般站長來說，這是「不用做任何事就變快」的好消息。幫客戶搬家、切換主機時，最怕改完 DNS 不知道要等多久，現在 Cloudflare 這一段又縮短了。

不過別把 3.3 秒當成「全世界 3 秒生效」。訪客那端的電信商 DNS 還會依 TTL 快取舊答案，所以搬主機前把 TTL 先調低、等舊快取過期，這個老規矩還是要做。

這篇我更欣賞的是工程上的態度：「不確定就做完整重建」、用鏡像環境比對正式流量再上線。自己做系統要做效能優化時，這種「先證明結果一樣才走捷徑」的思路很值得參考。

名詞小辭典

• DNS：把網址翻成伺服器位址的系統，像網路的通訊錄。
• TTL：DNS 答案可以被快取多久。TTL 設 1 小時，代表別人可能 1 小時內都還用舊答案。
• Kafka：一種訊息佇列系統，負責把「有東西改了」的通知依序送給下一個程式處理。
• p99：把所有等待時間排序後，第 99% 那一筆的數值，用來看「最慢的那一小群」有多慢。

資料來源

• Cloudflare Blog：How we halved DNS build delay and cut memory use by 85%（2026-11-02）