我最近“inheritance了”一个微小的bind9 DNS服务器（64MB内存，只运行bind9 + ssh），这些区域是使用GUI应用程序制作的，然后以root身份进入服务器。 我并不介意这一部分，但事实certificate，GUI应用程序在每次编辑时都会产生不一致的序列号，从而导致1245486432等序列，而不是“通用”（？）YYYYMMDDSS。
有没有一种“安全”的方式来增加/减less序列号，而不会导致DNS服务器和caching之间的任何不一致？
从机使用串行来确定它们所具有的区域文件是否与主机所拥有的修订版本相同。 当主人的序列增加时，他们知道他们必须AXFR一个新的副本。 唯一的伤害会来自于减less，因为奴隶会认为他们有一个比主人掌握的修改。
有两个解决scheme。 最简单的是减less你的主人，从奴隶删除副本，然后让他们重新加载。 但是，如果你不能完全控制奴隶，这是行不通的。 在这种情况下， 参考手册中提供了一个解决scheme。
将2147483647（2 ^ 31-1）添加到号码中，重新加载区域，并确保所有从站已更新到新的区域序列号，然后将号码重置为您想要的值，然后重新加载区域。
值得注意的是，最好使用串行的最后两位数字来存储修订版本，而不是秒。 即YYYYMMDDRR。 这允许您在同一天内进行多个更新。
我使用了一些“神奇”的DNS序列号algorithm来回到更常规的YYYYMMDDSSscheme，但是我确实拥有了可以去的安全网，并且在需要的时候手动强制奴隶提交和刷新caching。
RFC 1982定义了一个最大增量2147483647（2 ^ 31 – 1）， DNS和Bind Cookbook有一个用这种方法重置序列的方法。 基本上增加最大增量到你当前的序列，重新加载你的区域，等待奴隶拿起改变，改变序列到你想要的东西，再次重新加载你的区域。
增量是安全的，因为x> y是testing，但是为了减less你经常需要控制所有的奴隶，迫使他们加载（他们认为是）旧区域。
这取决于奴隶，但对于绑定最简单的方法是停止，从属文件，并开始。 如果您想了解这一点，可以通过RNDC强制重新加载。