[计算机网络]：DNSSEC原理( 三 ) _dns

（2）ZSK签名的数据量比较大，因而破解的概率较大，生存期应该小一些。因为有了KSK的存在，ZSK可以不必放到上一级的域名服务中，更新ZSK不会带来太大的管理开销（不涉及和上级域名服务器打交道）。
2.1.2 RRSIG记录
RRSIG资源记录存储的是对资源记录集合（）的数字签名。下面是对一个A记录签名后得到的RRSIG记录：
. 86400 IN RRSIG A 5 3(
203 2642 .
+p8WTr
…
+= )
从第五个字段（“A”）开始各字段的含义如下：
类型覆盖（The TypeField）：表示这个签名覆盖什么类型的资源记录，本例中是A；
算法：数字签名算法，同记录的算法字段；本例中5表示RSA/SHA-1 。
标签数量（TheField）：被签名的资源域名记录所有者（.）中的标签数量，如本例中为3，*..为2，“.”的标签数量为0 。
接下来的几个字段分别是被签名记录的TTL、有效期结束时间、开始时间。
然后（2642）是密钥标签（Key Tag），它是用对应公钥数据简单叠加得到的一个16比特整数。如果一个域有多个密钥时（如一个KSK、一个ZSK），Key Tag可以和后面的签名者字段（.）共同确定究竟使用哪个公钥来验证签名。
2.1.3 DS记录
DS（）记录存储的散列值，用于验证的真实性，从而建立一个信任链。不过，不象存储在资源记录所有者所在的权威域的区文件中，DS记录存储在上级域名服务器（）中，比如的DS RR存储在.com的区中。
下面是一个DS记录的实例：
. 86400 IN DS 60485 5 1 ()
DS 之后的字段依次是密钥标签（Key Tag）、算法、和散列算法（1代表 SHA-1）。后面括号内的内容是.密钥SHA-1计算结果的16进制表示。必须为这个记录数字签名，以证实这个的真实性。
2.1.4 NSEC记录
NSEC记录是为了应答那些不存在的资源记录而设计的。为了保证私有密钥的安全性和服务器的性能，所有的签名记录都是事先（甚至离线）生成的。服务器显然不能为所有不存在的记录事先生成一个公共的“不存在”的签名记录，因为这一记录可以被重放（）；更不可能为每一个不存在的记录生成独立的签名，因为它不知道用户将会请求怎样的记录。

文章插图
在区数据签名时，NSEC记录会自动生成。比如在和之间会插入下面的这样两条记录：
. 10800 IN A 192.168.1.100
NSEC . A RRSIG NSEC
RRSIG NSEC 5 5216 (
216 5271 .
Ujw/aq….= )
. 10800 IN A 192.168.1.200
其中NSEC记录包括两项内容：排序后的下一个资源记录的名称（.）、以及.这一名称所有的资源记录类型（A、RRSIG、NSEC），后面的RRSIG记录是对这个NSEC记录的数字签名。
在用户请求的某个域名在vpn和xyz之间时，如，服务器会返回域名不存在，并同时包括的NSEC记录。
2.2 对现有DNS协议的修改
由于新增DNS资源记录的尺寸问题，支持的域名服务器必须支持EDNS0（），即允许DNS报文大小必须达到1220字节（而不是最初的512字节），甚至可以是4096字节。
在报文头中增加了三个标志位：
（1）DO（ OK, 参见）：支持的解析服务器在它的DNS查询报文中，必须把DO标志位置1，否则权威域服务器认为解析器不支持就不会返回RRSIG等记录。
（2）AD （ Data）：AD是认证数据标志，如果服务器验证了相关的数字签名，则置AD位为1，否则为0 。这一标志位一般用于自己不做验证的解析器（non- -aware ）和它所信任的递归解析服务器（-awarename ）之间，用户计算机上的解析器自己不去验证数字签名，递归服务器给它一个AD标志为1的响应，它就接受验证结果。这种场景只有在它们之间的通信链路比较安全的情况下才安全，比如使用了IPSEC和TSIG[] 。