区域设置更改用于重建整个DNS区域，即使是有数千万条记录的区域。以下是我们如何构建一个规划器，选择最小的安全构建，将完整构建减少40%，峰值内存减少85%，并将构建延迟减半。当我上次在2022年撰写有关DNS传播管道的文章时， Zone Builder每秒收到约250次DNS记录更改。
今天，它收到了大约700个，几乎是原来的三倍，加上大约100个其他事件，例如区域设置更改。然而，事件的数量从来都不是真正的问题。问题在于这些活动所需的工作类型，以及这些工作如何随着区域的大小而增长。一些区域现在拥有超过2000万条记录，我们预计它们将不断增长，达到数亿条。
每个事件都会启动一个时钟，用于衡量我们将更改转换为权威DNS服务器可以使用的数据所需的时间。我们称之为构建。构建读取当前数据库状态，将其转换为边缘使用的格式，并将任何更改写入Quicksilver。2022年，每个记录的构建平均比完整构建快150倍。在一个拥有100万条记录的测试区域，每条记录的构建速度提高了4,250倍。
我们以明显的下一步结束了这篇帖子：对区域设置执行相同的操作。为什么区域生成器不直接重建已更改的设置？它应该是，这就是我们结束的地方。然而，证明什么时候是安全的占据了大部分工作。记录事件标识更改的内容。区域事件可以来自许多Cloudflare产品，可能无法说明区域更改的原因，并且可以更改多个同名区域共享的数据。
选择太多的工作会浪费产能。选择太少可能会在边缘留下陈旧或不正确的DNS数据。我们构建了一个有针对性的构建规划器，该规划器选择我们可以证明的最小构建是安全的，并且还构建了一个新的调度器，该调度器结合了同一区域的工作。区域设置更改不再重建包含数千万条记录的区域。