DNSゾーンの複雑さが増すにつれ、巨大なドメインの更新処理は重大なエンジニアリング上の課題となっています。Cloudflareの報告によると、一部のゾーンには現在2,000万以上のレコードが含まれており、これらの数は数億に達すると予想されています。以前のシステムは、変更を伝播させるために「フルビルド」に依存していました。フルビルドでは、ゾーンの現在のデータベース状態全体を読み取り、すべてのレコードを権威サーバーで使用される形式に変換し、Cloudflareの分散型キーバリューストアであるQuicksilver内の既存データと比較します。巨大なゾーンにとって、このプロセスは非効率です。なぜなら、ゾーン全体をメモリ内に保持する必要があり、利用可能な容量を超えてボトルネックが発生することが多いためです。

この問題を解決するために、Cloudflareは、正しい状態を維持するために必要な最小限の変更セットを特定するターゲットビルドプランナーを実装しました。システムは現在、更新を5つの特定のビルドタイプに分類しています。それらは、「リソースのみ」（標準的なA、AAAA、TXT、CNAMEの変更）、「リソースとメタデータ」（ネームサーバーおよびワイルドカードの変更）、「エイペックスとメタデータ」（Universal SSLなどの設定）、「パージ」（ゾーンの削除）、および「フルゾーン」（変更がターゲットに安全であると証明できない場合にのみ使用）です。プランナーは、各設定をコードを通じて追跡し、その影響を判断することで安全性を確保します。タイムスタンプのみの更新など、何が変更されたか特定できない曖昧な変更の場合、システムは古いデータや誤ったデータを配信するのを避けるために、デフォルトでフルビルドを実行します。

効率性は、同じゾーンの複数の保留中の変更を単一のビルド操作に統合する統合スケジューラによってさらに向上しています。これにより、複数の更新が短期間に連続して到着した際に、システムが冗長な作業を行うことを防ぎます。信頼性を維持するために、システムはKafkaを使用した「ソフトコミット」を採用しています。ビルドは順序を違えて完了する可能性がありますが、Kafkaのオフセットはすべての先行メッセージが完了したときにのみ進みます。これにより、ワーカーが再起動しても顧客の変更が失われないことが保証されます。ただし、最大のゾーンについては特定のトレードオフが存在します。ゾーンが固定のレコード数しきい値を超えた場合、システムはフルビルドの実行を拒否します。これは、フルビルドが必要だがメモリ制限内で完了することが技術的に不可能な稀なケースにおいて、システムが個々の名前を手動で再構築しなければならないことを意味しますが、単一の巨大なゾーンがKafkaパーティション全体をブロックするのを防ぎます。