10.4 增量区域传输（IXFR）
有了动态更新和NOTIFY功能，就可以随着网络状态的改变而更新区域数据，并且这些变动可以迅速传送至区域的所有权威名称服务器。看起来很完美，不是吗？
其实不尽然。在一个大型区域中，动态更新的频率是非常惊人的。不难想象：存在这样一个大型区域，其中包含上千个客户端，可是某天管理者突然决定使用Active Directory和DHCP。现在每个客户端都要更新自己在区域中的地址记录，并且域控制器（Domain Controllers）也会更新一些记录以便通知客户端它们提供了哪些服务。（第17章会对Active Directory做进一步介绍。）
每当primary名称服务器接收一条更新并增加区域的序号时，便会向它的slave发送NOTIFY通告。每当接收到NOTIFY通告时，这些slave就会向其master服务器查询区域的序号，并且有可能进行区域资料传输。如果该区域很大，则传输会花些时间；在此期间，可能又接收到一条更新。slave可能永远都在进行区域数据传输！另外，即便区域的变动可能非常小（例如，增加一条客户端地址记录），名称服务器却仍要浪费许多时间来传输整个区域的数据。
增量区域传输（Incremental zone transfer，IXFR）可以解决该问题。slave名称服务器可以告诉它们的master服务器，自己目前所持有的区域数据是哪个版本，而只要求发送该版本和当前版本之间有变动的部分即可。这样就可以大幅降低区域数据传输的大小和时间。
增量区域传输请求所使用的查询类型是IXFR而非AXFR（这个查询类型会启动整个区域数据的传输），并且消息的authority字段包含slave当前的区域SOA记录。当master名称服务器接收到增量区域传输请求时，它会查找slave和master所持有的区域数据版本之间发生改变的记录。如果该记录丢失，则master会发送完整的区域数据。否则，它只发送区域数据版本之间有差异的部分。
10.4.1 IXFR的局限性
听起来不错，不是吗？但是IXFR也存在一些局限性。首先，IXFR不能很好地运行在BIND 之前的版本上。不过所有BIND 9名称服务器都支持IXFR并且运行得很好，同时还可以跟BIND 8.2.3进行交互操作。
其次，IXFR适合工作在使用动态更新来修改区域数据的情况下，而不适用于手动更新。动态更新会记录下对区域数据及序号所作的变更，而这正是master名称服务器要向请求IXFR的slave发送的信息。但是重载整个区域数据文件的名称服务器，必须找出该区域和上个区域之间的差别，例如，对这两个版本执行diff。这意味着，如果想最大程度地发挥IXFR的作用，那么只能使用动态更新来修改区域数据，而绝不能手动编辑区域数据文件。
10.4.2 从差异中确定IXFR
BIND 开始支持通过比较区域数据文件和其在内存中的版本差别，来确定IXFR应答。这意味着现在（又）可以手动编辑区域数据文件了。然而必须采取预防措施，确保所编辑的区域数据文件是最新版本，并且在编辑期间拒绝动态更新。（动态更新会改变内存中的区域数据，从而导致区域数据文件不能反映实际状态。）
要开启这项功能，可以在options或zone语句中使用ixfr-from-differences子语句。下面的配置会对所有区域开启此项功能：
要强制名称服务器保存新版本的区域数据文件并且暂时停止该区域的动态更新，可以使用rndc的新命令freeze：
要通知名称服务器重载区域数据文件并且恢复区域的动态更新，可以使用rndc的thaw命令：
https://yqfile.alicdn.com/15b6c6366e2a4035032073ef5723ffa54c4cbfc1.png" >
不应该长时间冻结区域数据的更新，尤其是在可能漏掉重要的更新时。
**
10.4.3 IXFR相关文件**
除了动态更新日志文件，BIND 8名称服务器还会维护IXFR日志，用以记录对区域数据的改变。如同动态更新日志文件，名称服务器每收到一条更新，就会更新IXFR日志文件。和动态更新日志文件不同的是，IXFR日志文件永远不会被删除，不过可以配置名称服务器对超出指定大小的日志文件进行削减（trim）。BIND 8的IXFR日志文件名，默认由区域数据文件名加上.ixfr组成。
BIND 9名称服务器使用动态更新日志文件（logfile或称为journal file），来收集IXFR应答并维护区域数据的完整性。由于primary名称服务器根本不知道何时会用到这条区域变更记录，所以该日志文件不会被删除。BIND 9的slave会保存日志文件，即便它接收到的是区域的AXFR，因为它还可能是一个或多个slave的master名称服务器。
10.4.4 BIND 8的IXFR配置
在BIND 8中，配置IXFR相当简单。首先，在master名称服务器上，需要使用名为maintain-ixfr-base的options子语句，以便让其维护整个区域的IXFR日志文件，甚至包括以该名称服务器为slave的区域，因为这些区域可能有slave需要IXFR服务：
其次，需要告知slaves去向它们的master名称服务器请求IXFR服务。方法是使用一条新的server子语句support-ixfr：
https://yqfile.alicdn.com/e50ba71de1a7fc2370bb94797c78aa630269f43f.png" >
这样就完成了，除非想重命名master上的IXFR日志文件。这要使用一条新的zone子语句ixfr-base：
https://yqfile.alicdn.com/375d79d4c3082494feea7493f403758283dab464.png" >
还可以在名称服务器上配置，当IXFR日志文件超出指定大小时进行削减1：
一旦IXFR日志文件超过指定值100KB，名称服务器就会将其削减到指定大小。这100KB的弹性空间用来避免当日志文件达到极限值时，接下来的每条更新都会导致其被削减回指定大小。
使用many-answers区域传输格式可以使区域数据的传输更有效率。有关many-answers区域传输本章稍后会加以说明。
10.4.5 BIND 9的IXFR配置
在BIND 9的master名称服务器中，配置IXFR甚至更简单，因为不必做任何事情：该功能是默认开启的。如果想针对特定的slave服务器关闭该功能（应该不会想这么做，因为slave必定会请求进行增量数据传输），可以使用server的子语句provide-ixfr，其默认值是yes：
还可以将provide-ixfr作为options的子语句，在此所做的配置会应用到所有的slave（只要该slave没有在自己的server语句中明确配置provide-ixfr子语句）。
因为BIND 9的master名称服务器默认采用many-answers区域传输格式，所以不必专门配置transfer-format。
比较有用的是request-ixfr子语句，它可以被用在options或server语句中。如果混合使用了支持IXFR（IXFR-capable）和不支持IXFR（IXFR-impaired）的master，可以将slave的区域传输请求改为发送给支持IXFR的master：
从BIND 开始，BIND 9名称服务器支持使用options的子语句max-journal-size配置日志文件（journal file）的最大尺寸。