每次进行 DNS 更新时，bind 都会破坏我的区域文件。如果无法将块定义为常量，那么是否有可能使用 2 个或更多区域文件来描述一个域？一个区域文件用于固定 RR，另一个用于动态 RR。
最后，如果以上方法都不可能，那么每次 DNS 启动时是否可以恢复到原始区域文件？
作为最后的手段，我将不得不编写一个脚本来手动复制或创建基础区域文件，然后启动绑定。但这似乎不是正确的方法。
答案1
是的，一个区域可以有两个文件。此外，建议在子域中执行所有动态更新。将这两者结合起来，您可以使所有机器编辑保持独立。
将其添加到区域文件的末尾：
$INCLUDE dynamic-zone-file.conf dyn.example.com
然后，所有动态更新都将转到dynamic-zone-file.conf。此文件应该存在并且可以由用户写入named。
答案2
在我这里，我们将动态更新保存在它们自己的区域中。如果区域文件收到动态更新，我想不出任何保持其整洁的方法。我不确定您说“是否可以恢复到原始区域文件”是什么意思。您是说您不需要动态更新在 BIND 重新启动之间保持持久性吗？如果是这样，只需编写一个脚本，在 BIND 启动之前将您存储和编辑的主区域文件复制到某个地方。
答案3
定义“mangle”。如果您指的是“重写”，那么是的，每次更新时，BIND 都需要重写区域文件。我的政策一直是，一旦区域文件开放进行动态更新，就再也不会手动修改它，您必须使用自动更新机制来执行任何操作（大量nsupdate调用，或者仅使用我们设置的 Web 界面 API）。
回答您的其他问题：
“是否有可能有两个或更多区域文件描述一个域？”——BIND 中“域”的正确术语是“区域”，因此如果我们将您的问题改写为“是否有可能有两个或更多区域文件描述一个区域？”，答案就变得非常明显了。如果您需要这样的东西，请像 mghocke 所描述的那样，有两个单独的区域。
“每次 DNS 启动时，是否可以恢复到原始区域文件？”——当然，只需让您的 DNS 启动脚本将基本区域文件复制到位即可。没有更好的方法可以做到这一点，因为这不是任何人都想做的事情——接受动态更新，然后在每次重新启动 DNS 服务器时将其丢弃。这种方法的一个警告是，您需要在复制基本区域文件时更新序列，否则您的从属服务器将不会进行区域传输。
我的灵力暗示你试图将手动（直接）编辑区域文件与动态更新混合在一起。你要知道，这行不通（在天真的情况下）——迟早你会陷入动态更新和手动文件编辑之间的竞争，而动态更新将获胜，导致你的手动更新失败。每次你想要编辑时，你都需要冻结和解冻区域（祝你好运，普遍执行那一）。这就是我制定“对动态区域的所有编辑都必须通过 DDNS 接口进行”政策的原因。