BIND 9

CHAPTER 4. 高级DNS特征 4.3. 增量区传送(IXFR)
(dump)操作延迟15 分钟,以允许其它更新。在转储过程中,将会创建以.jnw和.jbk为后缀的瞬时
文件;在普通情况下,这些文件将在转储完成后被删除掉,忽略它们也是安全的。
当服务器在停止或宕掉之后重启时,将重新装载日志文件,以将自从上次区转储以后发生的所有更新合
并到区中。
增量区传送所产生的变化也是以类似的方式记录到日志的。
动态更新区的区文件不能象通常那样进行手工编辑,因为没法保证包含最近的动态变化,这些变化只存
在于日志文件中。保持动态更新区的区文件最新的唯一方法是执行rndc stop。
如果你必须手工修改动态区,需要按照下列步骤:使用rndc freeze zone关闭动态更新。这同时会删除
区的“.jnl”文件并更新主文件。编辑区文件。执行rndc thaw zone重新装载修改后的区文件并打开
动态更新。
4.3 增量区传送(IXFR)
增量区传送(incremental zone transfer, IXFR)协议是一个为辅服务器提供只传送变化的数据的方式,
以代替必须传送整个区的方法。IXFR协议由RFC 1995 指定。参见[建议标准]。
作为一个主服务器,BIND 9支持IXFR 协议,为区提供必要的变化历史的信息。这些包括以动态更新维
护的主区和通过IXFR获取数据的辅区。对于手工维护的主区,以及通过全区传送(AXFR)获取数据的
辅区,IXFR仅在ixfr-from-differences选项被设置成yes时才支持。
作为一个辅服务器,BIND 9将尝试使用IXFR,除非其被显式地关闭。更多关于关闭IXFR 的信息,参
见server 语句的request-ixfr子句的描述。
4.4 分割DNS
对DNS空间的内部和外部解析器设置不同的视图,或可见度,通常被称为一个分割的DNS设置。有几个
原因使某个单位想要这样设置其DNS。
一个以此方式设置DNS系统的共同的原因是对“外部”互联网上的客户隐藏“内部”DNS信息。关于这
样做是否确实有用,有一些争议。内部DNS信息以多种渠道泄露(例如,通过电子邮件头部),并且大
多数聪明的“攻击者”可以使用其它手段来取得他们所需要的信息。无论如何,由于列出外部客户端不
可能访问到的内部服务器地址可以导致连接延迟和其它烦恼,一个单位可以选择使用一个分割DNS来向
外部世界提供一个一致的自身视图。
另一个设置一个分割DNS系统的共同的原因是允许在过滤器之后或在RFC 1918空间(保留IP空间,
在RFC 1918中说明)中的内部网络去查询互联网上的DNS。分割DNS也可以用于允许来自外部的回复邮
件进入内部网络。
4.4.1 分割DNS设置的例子
让我们假设一个名叫Example的公司(example.com)有几个公司站点,有一个使用保留地址空间的
内部网络和一个外部停火区(DMZ),或称为网络的“对外”部份,是外部可以访问到的。
Example公司想要其内部的客户端可以解析外部主机名并同外面的人们交换电子邮件。公司也想要其
内部的解析器可以访问某些内部才有的区,这些区对内部网络之外的用户不可用。
为达到这个目标,公司设置两台名字服务器。一台在内部网(在保留地址空间),另一台在DMZ中
的堡垒主机上,堡垒主机是一个“代理”主机,它可以同其两侧的网络通信。
内部服务器配置成除了对site1.internal,site2.internal,site1.example.com和site2.
example.com之 外 的 所 有 请 求 都 转 发 给 在DMZ的 服 务 器 。 这 些 内 部 服 务 器 都 有 关 于site1.
example.com,site2.example.com,site1.internal和site2.internal的全部信息。
为保护site1.internal和site2.internal域,内部服务器必须配置成不允许任何外部主机对这
些域的请求来访问,其中也包括堡垒主机。
22