第4章 高级概念

目录

4.1. 动态更新

4.2. 增量数据传送（IXFR）

4.3. 分开的DNS？

4.4. TSIG

4.5. TKEY

4.6. SIG(0)

4.7. DNSSEC

4.8. IPv6支持

4.1. 动态更新

动态更新这个术语是指在指定的条件下增加、修改或者删除管理域文件中的记录或RR设置。这个特性完整描述在RFC 2136。

动态更新（Dynamic update is enabled on a zone-by-zone basis），通过zone 语句中的allow-update 或者update-policy 子句启用。

更新秘密区域 (使用DNSSEC的区域) 按RFC 3007: SIG的规定， 服务器使用在线区域关键字自动更新NXT 记录。主管理区域则基于信号和直接的服务器策略。

4.1.1. 日程文件

一个区域所有的动态更新都被存储在区域的日程文件（zone's journal file）。这个文件是动态更新第一次发生时服务器自动产生的，日程文件的名字都是对应的区域文件后面加上.jnl扩展名。日程文件是二进制格式的，不能手工编辑。

服务器有时候也把整个更新过的区域文件的内容存入("dump")一个区域文件中。这并不是在动态更新后就立即执行，因为一个很大的区域文件如果很频繁的更新，将会使服务器变的很慢。实际上这个保存（dump）过程会后延15 分钟，允许马上又发生其它更新。

当服务器关机或崩溃后重启，它会读入日程文件，如果记录日程文件后发生的变化就会丢失。

区域数据增加也使用日程文件，方法相似。

动态变化的区域文件不能手工编辑是因为它们不能保证是最新的，要保证它是最新的唯一方法就是运行rndc stop。

如果必须手工改变动态区域数据，按下面的流程操作：使用rndc stop 关闭服务(发信号或者 rndc halt 不行)，等服务器退出后，删除（remove ）区域的.jnl文件，编辑区域数据文件，然后重启服务。删除.jnl 文件是必须的，因为存在日程文件时，手工编辑的内容不会有效。

4.2. 增量区域数据传送（Incremental Zone Transfers (IXFR)）

增量区域数据传送(IXFR)是为从属服务器只传送改变部分数据的协议。不同于必须传送整个区域数据。详情参见RFC 1995. Proposed Standards.

作为一个管理区域服务器时， BIND 9 支持IXFR，提供必要的区域数据改变历史信息。这些包括被动态更新维护的管理区域数据和从IXFR接收数据的从属服务器的区域信息，但是手工维护的管理区域数据和从属区域数据必须执行完整的区域数据传送（a full zone transfer (AXFR)）.

作为从属服务器时， BIND 9会尝试使用IXFR特性，除非明显的禁止这个功能。如何禁止IXFR，参看server语句中的request-ixfr 子句。

4.3. 分离DNS（Split DNS）

从不同的视角去看，DNS空间可以分为内部的外部的，这样可能会用到分离DNS。一个组织会有多个原因将DNS设置成分离状态。

一个通常的原因是向互联网上的“外部”用户隐藏“内部”DNS信息。有一些关于这个措施是否有用的辩论。互联网DNS信息泄漏有很多渠道 (例如，通过电子邮件的头部数据) ，许多聪明的“攻击者”会用其它方法找到这些信息。

第二个原因是允许在过滤器后面的内部网络用户或者RFC 1918里面的地址 (保留 IP地址段, 文档见RFC 1918)使用DNS解析。分离DNS也允许用于外部邮件回到内部网络中。

下面是分离DNS设置的例子：

假定一个公司名字是Example, Inc. (example.com) ，有几个站点，使用保留IP地址空间的内部网络和外部的非军事区 (DMZ), 或者可以与外网通讯的部分。

Example公司希望内网客户能够解析外网的主机名，并且可以和外网进行邮件交换。公司也希望内部解析器能够存取一些只有内部网才可访问的区域数据，这些部分外部网络都不能访问。

为了完成这个需求，公司需要建立两组域名服务器，一组在内部网中，使用保留IP地址空间，另一组是堡垒主机，他们像代理服务器那样，可以同时和外、内网通讯，他们在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 这两个域，内部服务器必须配置不允许所有外部主机查询它，包括堡垒主机。

在DMZ的堡垒主机，外部服务器将会把site1 和site2.example.com 区域配置成“公开”型。这包括公众服务器的主机记录 (www.example.com 和ftp.example.com)， 和邮件交换记录（mail exchange (MX)），如a.mx.example.com 和b.mx.example.com。

另外，公众服务器的site1 和 site2.example.com 区域数据应该指定MX 记录包含通配符(`*')，指向堡垒主机，这是因为外部邮件服务器没有任何其它办法找到如何传送邮件到他们内部的主机。使用通配符记录，邮件将会传送到堡垒主机，然后转发到内部主机。

这是通配符MX记录的例子：

*   IN MX 10 external1.example.com.

现在，他们按内部网络的行为要求接收邮件，堡垒主机需要知道如何传送邮件到内部网主机中，为了使它工作正常，堡垒主机的解析器需要设置以指明由内部DNS解析。

查询内部主机由内部服务器应答，查询外部主机将由堡垒主机转发。

为了使这些都工作正常，内部主机需要配置只查询内部DNS服务器，这也可以通过一个选择过滤器来强迫执行。

如果一切都设置正确， Example, 公司的内部用户将可以：

·         查询site1 和site2.example.com 区域中所有的主机。

·         查询site1.internal 和site2.internal 域中所有的主机。

·         查询互联网上所有的主机。

·         和内部网、外部网的用户交换邮件。

互联网主机可以：

·         查询site1 和site2.example.com 区域中所有的主机。

·         和site1 、site2.example.com 中所有用户交换邮件

这是我们前面描述的范例配置，注意这只是配置信息，如何配置区域数据文件，参看Section 3.1

内部DNS服务器配置：

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {

    ...

    ...

    forward only;

    forwarders {                                // forward to external servers

        bastion-ips-go-here; 

    };

    allow-transfer { none; };                   // sample allow-transfer (no one)

    allow-query { internals; externals; };      // restrict query access

    allow-recursion { internals; };             // restrict recursion

    ...

    ...

};

zone "site1.example.com" {                      // sample master zone

  type master;

  file "m/site1.example.com";

  forwarders { };                               // do normal iterative

                                                // resolution (do not forward)

  allow-query { internals; externals; };

  allow-transfer { internals; };

};

zone "site2.example.com" {

  type slave;

  file "s/site2.example.com";

  masters { 172.16.72.3; };

  forwarders { };

  allow-query { internals; externals; };

  allow-transfer { internals; };

};

zone "site1.internal" {

  type master;

  file "m/site1.internal";

  forwarders { };

  allow-query { internals; };

  allow-transfer { internals; }

};

zone "site2.internal" {

  type slave;

  file "s/site2.internal";

  masters { 172.16.72.3; };

  forwarders { };

  allow-query { internals };

  allow-transfer { internals; }

};

外部 (堡垒主机) DNS服务器配置：

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {

  ...

  ...

  allow-transfer { none; };                     // sample allow-transfer (no one)

  allow-query { internals; externals; };        // restrict query access

  allow-recursion { internals; externals; };    // restrict recursion

  ...

  ...

};

zone "site1.example.com" {                      // sample slave zone

  type master;

  file "m/site1.foo.com";

  allow-query { any; };

  allow-transfer { internals; externals; };

};

zone "site2.example.com" {

  type slave;

  file "s/site2.foo.com";

  masters { another_bastion_host_maybe; };

  allow-query { any; };

  allow-transfer { internals; externals; }

};

在堡垒主机的resolv.conf (或其它相似的)：

search ...

nameserver 172.16.72.2

nameserver 172.16.72.3

nameserver 172.16.72.4