DNS 面临的安全问题：
Host Enumberation :主机枚举  应该限定用密钥进行传送
用TSIG ： 事物签名  来解决

TSIG: Transaction Signatures  事物签名

基于对称密钥加密技术的的DNS报文认证机制。密钥生成后存放至通信双方的配置文件中，报文传送前使用此密钥进行“签名”。事实上，由于使用的是对称加密技术，这里并不是实现了真正意义上的数字签名，而没有使用公钥加密技术的主要原因是基于速度的考虑。于是，出于安全的角度考虑，任何两台主机之间通信都应该使用特定的密钥。

使用dnssec-keygen命令可以生成密钥：
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST ns-ns2.mm.com.
生成一个密钥，把密钥配置到双方主机的主配置文件中，不能被别人读取到，定义好双方主机就可以实现密钥认证了。
 -a algorithm
  如果不指定算法，默认使用RSASHA1；事实上，对于DNSSEC来说只能使用RSASHA1算法,对TSIG来说, HMAC-MD5是强制使用的算法.
 -b keysize
  使用不同的算法，其支持的密钥长度不同。RSA: 512-2048, DH：128-4096， HMAC：1-512
 -n nametype
  密钥的拥有者，即其使用级别；共有ZONE (DNSSEC zone key (KEY/DNSKEY)), HOST or ENTITY (host (KEY)), USER (a user(KEY)) or OTHER (DNSKEY)，默认是ZONE。
 {name}
   The name of the key is specified on the command line. 对DNSSEC来说，名字必须是密钥所服务的ZONE的名称；对于TSIG来说，这通常是通信双方的名字；

在两台主机上配置：

ns.mm.com: 172.16.9.1
ns2.mm.com: 172.16.9.2

在任一台主机上使用命令：dnssec-keygen -a HMAC-MD5 -b 512 -n HOST ns-ns2.mm.com.
生成了两个文件：Kns-ns2.mm.com.+157+57026.key和Kns-ns2.mm.com.+157+57026.private。

查看private文件的内容如下：
cat Kns-ns2.mm.com.+157+59024.private
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: ZihuWXfBgktFRNoBl/olSSuK5RUJ/MkroYvuT00RY8IWQhFPjXpFMner1Qlqkpp9wl6hxaytn7VCJyVD2HXU+A==
Bits: AAA=
Created: 20121020133849
Publish: 20121020133849
Activate: 20121020133849

主要用到key那行的密钥的.
 
此文件中的Key需要保存至两台主机的主配置文件named.conf中使用，但必须保证named.conf文件不能被所有人读取。或者，也可以将密钥定义单独保存至某文件，使其不能被所有人读取，而后在named.conf文件中使用include指令将其包含进来。

在通信双方的named.conf中定义密钥的格式如下：
key "ns-ns2.mm.com." {
 algorithm hmac-md5;
 secret "ZihuWXfBgktFRNoBl/olSSuK5RUJ/MkroYvuT00RY8IWQhFPjXpFMner1Qlqkpp9wl6hxaytn7VCJyVD2HXU+A==
Bits: AAA="
                                                                               //key行的密钥
};

而后在每个主机上定义分别定义通信的对方，这里在ns.mm.com上定义：
server 172.16.100.2 {
 keys { ns-ns2.mm.com.; };
};

 在ns2.mm.com上定义：
server 172.16.100.1 {
 keys { ns-ns2.mm.com.; };
};

如果主服务器仅允许通过认证的从服务器进行区域传送，则可以使用类似如下格式定义传送限制：

zone "mm.com" IN {
        type master;
        file "mm.com.zone";
        allow-transfer {127.0.0.0/8;   key "ns-ns2.mm.com."; };     //在mm.com 的区域中定义（可以参考上篇文章）

}；

检测下语法错误，重启下named服务，基于密钥的传送机制就完成了！！

 

 

注：TSIG在DNS服务器实现安全通信具有重要的意义，但也有着诸多缺陷。一是其使用基于对称密钥的认证机制使得密钥的管理和分发变得困难，因此其也不适用于互联网级别的应用，而仅能服务器企业；二是其仅提供至“下一跳”的安全性，因此较适用的场景仅是迭代查询的场景和主从之间的区域传送；三是DNS本身就是公共资源，它需要将结果公开给互联网，因此无法实现结果的机密性。四是目前为止，Linux的客户端尚不支持查询时对服务器进行认证。

 

提醒一下：数据文件内容修改的话别忘了序列号上加1 哦 O(∩_∩)O~。。