每次DNS更新完成时绑定我的区域文件。 如果将块定义为常量是不可能的，是否可以有2个或更多的区域文件描述一个域？ 作为一个区域文件的意图是针对固定的RR，而另一个针对dynamic的RR。
最后，如果以上都不可能，每次DNS启动时是否可以恢复到原来的区域文件？
作为最后的手段，我将不得不编写脚本来手动复制或创build基本区域文件，然后开始绑定。 但是，这似乎并不是正确的做法。
是的，您可以为单个区域创build两个文件。 另外build议做一个子域中的所有dynamic更新。 结合这两个你可以保持所有的机器编辑隔离。
将此添加到您的区域文件的末尾：
$INCLUDE dynamic-zone-file.conf dyn.example.com 所有dynamic更新然后将进入dynamic-zone-file.conf 。 这个文件应该存在并且可以被named用户写入。
在我的地方，我们保持dynamic更新包含在自己的区域。 如果接收到dynamic更新，我想不出有什么办法保持区域文件整洁。 我不确定你想说什么“是否有可能恢复到原来的区域文件”。 你是否说你不需要dynamic更新在BIND重启之间持续存在？ 如果是这样的话，只需编写一个脚本来复制您在BIND启动之前存储和编辑的主区域文件。
定义“mangle”。 如果你的意思是“重写”，那么是的，BIND需要在每次更新时重写区域文件。 我的策略是，一旦区域文件打开进行dynamic更新，永远不会再次手动修改，而且必须使用自动更新机制来执行任何操作（大量的nsupdate调用，或者使用我们设置的Web界面API ）。
回答你的其他问题：
“是否有可能有2个或更多区域文件描述一个域？ – BIND中“domain”的正确名称是“zone”，所以如果我们把你的问题重写为“是否有两个或两个以上的区域文件描述一个区域？”，答案就变得非常明显。 如果你需要类似的东西，就有两个独立的区域，正如mghocke所描述的那样。
“每当DNS启动时，是否可以恢复到原来的区域文件？ – 当然，只需将您的DNS启动脚本复制到基本区域文件。 没有更好的办法来做到这一点，因为它不是任何人都想做的事情 – 接受dynamic更新，然后在每次重新启动DNS服务器时将其丢弃。 使用这种方法需要注意的一点是，当您复制基本区域文件时，您需要更新串行，否则您的从站将不会执行区域传输。
我的精神力量build议您尝试将手动（直接）编辑与具有dynamic更新的区域文件混合使用。 只是如此你知道，这是行不通的（在天真的情况下） – 迟早你会在一个dynamic更新和手动文件编辑之间的比赛，dynamic更新将赢得，导致丢失手动更新。 每次你想编辑时，你都需要冻结和解冻区域（祝你好运，普遍执行那个 ）。 这是我的“所有dynamic区域编辑必须通过DDNS接口”策略完成的原因。