[原创] 10.4. Incremental Zone Transfer (IXFR)

10.4. Incremental Zone Transfer (IXFR)

 

1、在一个快速变化的环境中，要及时更新主机信息，单靠动态更新和NOTIFY机制是不够的 ：如果一个很大的 zone ，拥有很多客户机，且频繁的发生动态更新。每次主服务器更新它的某个 zone 的序列号时，就会发送一个 NOTIFY 消息给它的从服务器。从服务器就会发送 SOA query ，甚至还会进行 zone transfer。假如这个 zone 很大，则整个 zone 的 transfer 将会很耗时间。假如这个期间主服务器又收到其他的动态更新，又发出 notify 消息，而这时候从服务器还没有结束前一个 zone transfer 。这样就变成从服务器无时无刻都在进行 zone transfer

2、增量区传送 IXFR 解决这个问题。从服务器告诉主服务器它所拥有的某个 zone 的当前版本是多少，并请求在该版本和主服务器的最新版本之间的那些更新。这就减少了 zone transfer 的时间和需要传送的数据量。

3、IXFR 的限制 ：

Ø         IXFR 只有在 BIND 9 才能很好的工作。IXFR 只有在 BIND 8.2.3 开始才有。

Ø         其次 IXFR 最好同动态更新一起配合。因为动态更新有日志文件记录到底做了那些修改，如果是手工修改的话，则不会在日志文件中有所记录。当从服务器请求 IXFR 时，就会漏掉手工修改的那些操作，只执行动态更新的那些操作。就造成了主从服务器的数据不一致情况。而且这种不一致是一直持续下去的，不会因为后续的 IXFR 而消除。除非后续的动态更新把前面的手工操作部分的动作给抵消了。

4、如果意外编辑了采用动态更新的 zone data files 怎么办 ？

为了利用 IXFR ，你必须只使用动态更新或者 nsupdate 命令来修改 zone data，而不是手工修改 zone data files。一旦你不小心手工编辑了 zone data file ，就必须确保日志文件中的操作已经被写入磁盘上的 zone data file ，然后删除该 zone 对应的日志文件。这样主服务器在下一次从服务器请求 IXFR 时就会发送 AXFR  了。可以使用 rndc stop 命令把日志中的动态更新记录写入磁盘的 zone data files。但这样需要重新启动 BIND 服务。如果日志中的操作没有提交就删除了日志文件，等于丢失了部分的动态更新操作，只保留了手工编辑的那个操作

5、BIND 8 的动态更新和 IXFR 的日志文件是分开的。就像动态更新的日志一样，在收到一个更新时就会更新 IXFR 日志。但不像动态更新的日志，IXFR 的日志是永远不会自动删除的。但可以配置它在超过一定大小时就截掉前面的内容。BIND 8 的 IXFR 日志文件名称是 ".ixfr" 。而 BIND9 使用动态更新的日志文件作为 IXFR 日志文件。

6、BIND 8 的 IXFR 配置 ： 

配置语句	适用类型	作用
options {   maintain-ixfr-base yes; };	主	为所有的 zone 都维持一份 IXFR 日志
server “” {   support-ixfr yes; };	主	表明自己支持 IXFR 功能
zone “xxx” {   ixfr-base “”; };	主	定制某个 zone 的 IXFR 日志文件的名称和位置
options {   max-ixfr-base-size N; };	主	IXFR 日志的最大容量。 注 ：日志的最大容量是 N ~ N+100KB。当日志超过指定大小的100KB后，name server 就会删除前面的部分，使文件退回到指定的大小。100KB 是一个缓冲的作用
options {   transfer-format many-answers; };	主	采用一个TCP packet 包含多个 RR 的格式进行区传送

 

7、BIND 9 的 IXFR 配置 ：

配置语句	适用类型	作用
options {   provide-ixfr yes; };	主	全局使用 IXFR 。默认就是这样，不需要定义
server “” {   provide-ixfr no; };	主	对某个不支持 IXFR 的从服务关闭 IXFR 功能
server “master_server_ip” {   request-ixfr yes; };	从	某个支持IXFR的从服务器向主服务器申请 IXFR 格式的区传送