4.4. 信号传送

信号传送（Transaction SIGnatures ，TSIG）

这里是BIND中基于加密信号传送的简单介绍 (TSIG) 。描述配置文件是否发生变化和发生了什么变化，包括在BIND中建立传送关键字和使用信号传送。

BIND主要支持服务器到服务器的信号传送（TSIG），这包括区域数据传送，告知和递归查询讯号，BIND 8版本有限制支持TSIG。

TSIG 对动态更新最有用。一个动态区域使用存取控制和控制更新，但是基于IP的存取控制是不够的。基于关键字的存取控制要好的多，参看 Proposed Standards。Nsupdate程序通过-k 和 –y命令选项支持TSIG。

为每一对主机生成共享关键字（Shared Keys ）

产生两台主机host1 和 host2共享密钥，任意给这个密钥字起个名字"host1-host2."，这个名字在两台主机里必须一样。

自动产生

下面的命令将会自动产生128 位 (16 字节) HMAC-MD5的密钥。更长的密钥更好，但短一些容易讲习。最长允许512 位，长于512位将会被按MD5的方法产生一个128位的密钥。

dnssec-keygen -a hmac-md5 -b 128 -n HOST host1-host2.

密钥在文件Khost1-host2.+157+00000.private中，没有直接使用这个文件，但是在”Key:”后64位编码的字符串能够将这个文件的内容扩展出来并作为共享密钥。

Key: La/E5CjG9O+os1jq0a2jdA==

字符串 "La/E5CjG9O+os1jq0a2jdA==" 就被用作共享密钥。

手工产生

共享密钥只是一个简单的随机位序列，编码成64位，大多数ASCII字符串都是有效的64位编码 (分设长度是4的倍数并且只使用有效的字符), 这样，就可以手工产生共享密钥。

而且，一个已经的字符串可以通过mmencode 或者相似的程序产生64位的编码数据。

把密钥拷贝到两台主机中

通过第一台（如：DNS. A）的安全传送机制完成，例如通过secure FTP, ssh, telephone, 等等。

通知服务器密钥已经存在

假设host1 和host 2 是两台服务器，把下面的代码加入到两台主机的named.conf 中：

key host1-host2. {

  algorithm hmac-md5;

  secret "La/E5CjG9O+os1jq0a2jdA==";

};

hmac-md5是唯一被让服务器使用密钥

既然密钥只在两台主机之间使用，那就必然告诉服务器何时使用这个密钥，把下面的代码加入到host1的named.conf 文件中，（假定host2 的IP地址是10.1.2.3）：

server 10.1.2.3 {

  keys { host1-host2. ;};

};

可能会列出多个密钥，但只有第一个会被使用， 这样写并不包含任何秘密，它应该在可读文件中。

如果host1 向某个特定地址发送一个信息，这个信息就会被指定的密钥加密，而它等期待回应信息也使用相同的密钥加密。

host2 的配置文件中必须有相似的语句 (和 host1 的地址) ，用来为host2 签名到host1的信息。

基于TSIG密钥的存取控制

在ACL定义和allow-{ query | transfer | update }中，BIND允许IP地址和地址段，这也被扩展到允许TSIG 密钥。上面的密钥用来表示key host1-host2。

一个allow-update的例子会是：

allow-update { key host1-host2. ;};

这将只允许使用"host1-host2."签名的请求进行动态更新。

有关update-policy 更多的内容请参看Section 6.2.22.4.

错误

TSIG签名信息运行过程中会出现一些错误，如果一个签名信息发送到了个没有不认识TSIG签名的服务器，将会回应一个FORMERR信息，因为那个服务器不能理解这个记录。这是错误配置的结果，一台服务器必须明确配置发送TSIG信息到一个指定的服务器

如果一个认识TSIG信息的服务器接收到了一个被未知密钥加密的信息，它不能识别这个信息，它会回应一个不加密的TSIG扩展信息码BADKEY，如果一个认识TSIG信息的服务器接收到了一个加密的无效信息，它会回应一个不加密的TSIG扩展错误信息码BADSIG。如果一个认识TSIG信息的服务器接收到一个超时的信息，它会回应一个加密的TSIG扩展错误信息码BADTIME，同时，时间值将会被调整，以便回应信息能够到达并验证。以上这些情况下，信息刻录都设置为NOTAUTH。

TKEY是一个两台主机间自动生成共享密钥的机制，它有现几种工作模式，用来指明密钥如何产生或是指定。

由密码保护的DNS信息也可能通过DNS Security (DNSSEC：加密扩展) ，在RFC 2535中定义，本节描述DNSSEC密钥的产生和使用。

为了建立一个 DNSSEC加密的区域，需要如下好几个步骤。密钥产生

dnssec-keygen程序用来生成密钥。

加密的区域必须包含一个或多个密钥。这个区域密钥会加密区域中的其它记录，就像指定加密字的区域一样。区域密钥必须与区域同名，名字类型的ZONE，必须可以使用管理。推荐区域密钥使用由IETF提供的加密算法"mandatory to implement" ，当前它们是RSASHA1 (BIND 9.2中还不支持) 和DSA。

下面的命令将会为child.example zone产生一个768位的DSA密钥：

dnssec-keygen -a DSA -b 768 -n ZONE child.example.

会产生两个文件： Kchild.example.+003+12345.key 和 Kchild.example.+003+12345.private (这里12345是密钥标签的例子)。密钥文件饮食了密钥名 (child.example.)，算法(3 是DSA, 1 是 RSA, 等等)，和密钥标签 (这个例子里是12345)。私钥(在 .private 文件里) 用来产生签名，公钥 (在 .key 文件里) 用来作签名校验。

产生相同属性的另外一个密钥 (但拥有不同的标签)，重复上面的命令。

公钥应该插入到区域文件中，使用$INCLUDE语句，用来引入.key 文件。

建立密钥组（Creating a Keyset）

dnssec-makekeyset 程序用来从一个或多个密钥中建立建立密钥组。

区域密钥产生后，就需要建立向其父域传送的密钥组，以便父域可以签名它自己的区域密钥，正确知道这个区域的加密状态。当建立一个密钥组时，必须要有一组密钥、生存时间（TTL），和希望的父域的签名有效期。

密钥组中一组密钥也可能包括区域上部的非区域密钥（non-zone keys），dnssec-makekeyset 也会用在区域中其它的名字上。

下面的命令产生的密钥组包含上部密钥和其它密钥的产生，规定TTL 值是3600，签名有效期是10天，从此时开始。

dnssec-makekeyset -t 3600 -e +864000 Kchild.example.+003+12345 Kchild.example.+003+23456

命令产生输出一个文件：keyset-child.example.. 这个文件应该传送给它的父域（用来签名）。它引用这些密钥，和被区域密钥自身产生的密钥组签名一样，用来证明拥有私钥和编码期望的有效期。

签名子域的密钥组

dnssec-signkey 程序用来签名子域的密钥组。

如果child.example 区域有加密的授权，例如grand.child.example，那么，child.example 管理员应该得到每个加密子域的密钥组文件，这些密钥必须被本域的密钥加密。

下面命令使用本域密钥加密子域密钥组：

dnssec-signkey keyset-grand.child.example. Kchild.example.+003+12345 Kchild.example.+003+23456

产生一个输出文件， signedkey-grand.child.example. ，这个文件需要传送回子域并在本地保留，它包含了所有的密钥 (子域的密钥)，并且使用本地密钥加密。

加密区域数据

dnssec-signzone 程序用来加密区域数据。

任何密钥文件对应的加密子域都要指明，就像父域为本域产生的一样，区域加密会为本域产生NXT 和SIG 记录，就像合并从父域的区域密钥签名和在所有需要的部分指明加密状态。

下面的命令加密区域数据，假定一个文件叫zone.child.example，默认情况下，所有拥有可用私钥的区域密钥都用来产生签名：

dnssec-signzone -o child.example zone.child.example

输出一个文件： zone.child.example.signed. 这个文件将在named.conf 中用到，作为区域数据的输入文件。

配置服务器

不像在支持的IPv6

BIND 9完全支持所有现在定义的IPv6域名和地址，当它运行在IPV6系统上时，它会使用IPv6 地址查询。

对于转发查询， BIND 9 支持A6 和 AAAA 记录， A6 记录的使用已经被转移到实验中(RFC 3363)，并不受重视了。

为IPv6使用位串（ "bitstring"）标记 转移到实验中 (RFC 3363)，回复是nibble格式的， IPv6转换的后缀也从IP6.INT 变成IP6.ARPA (RFC 3152).

BIND 9 现在默认是nibble IP6.ARPA 格式查询。.

BIND 9 包含了一个轻量级的解析库和解析后台，新程序可以用来避免复杂的A6串和位串标记，参看 Chapter 5。

关于IPv6地址的格式和结构，参看Section A.3.1。

使用 AAAA 记录查询地址

AAAA 记录与IPv4的A 记录是平行的，它在一个记录中指明完整的地址。例如：

$ORIGIN example.com.

host            3600    IN      AAAA    2001:db8::1

使用Nibble 格式查询地址

当使用nibble 格式查询时，会简单的返回一个地址，就像在IPv4中一样， IP6.ARPA. 被加到查询结果中，例如，下面将会为2001:db8::1.进行域名查询：

$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0   14400 IN      PTR     host.example.com.