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

（3）CD （）：关闭检查标志位用于支持验证功能的解析器（ -aware ）和递归域名服务器之间，解析器在发送请求时把CD位置1，服务器就不再进行数字签名的验证而把递归查询得到的结果直接交给解析器，由解析器自己验证签名的合法性。
最后，支持验证的解析器对它所收到的资源记录的签名（RRSIG），必须能够区分区分以下四种结果：
（1）安全的（）：解析器能够建立到达资源记录签名者的信任链，并且可以验证数字签名的结果是正确的。
（2）不安全的（）：解析器收到了一个资源记录和它的签名，但是它没有到达签名者的信任链，因而无法验证。
（3）伪造的（Bogus）：解析器有一个到资源记录签名者的信任链，但是签名验证是错的。可能是因为受到攻击了，也可能是管理员配置错误。
（4）不确定（）：解析器无法获得足够的资源记录，因而不能确定用户所请求的资源记录是否应该签名。
3 的配置
尽管的工作原理看起来让人气馁，实际的配置操作却并不复杂。本节以BIND 9为例介绍的基本配置。尽管BIND 9.3以上就开始支持，仍然建议使用当前最高版本的BIND（当前最新的版本是9.8）。
配置或布署有两种场景：
（1）配置安全的域名解析服务器（），该服务器可以保护使用它的用户，防止被DNS 欺骗攻击。这里只涉及数字签名的验证工作。
（2）配置安全的权威域名服务器（Name ），对权威域的资源记录进行签名，保护服务器不被域名欺骗攻击。
3.1 配置安全解析服务器3.1.1 激活
首先，在BIND的配置文件（一般是/etc/named.conf）中打开选项，比如：
{
“/var/named”;
- yes;
….
};
3.1.2 配置Trust
其次，要给解析服务器配置可信锚（Trust ），也就是你所信任的权威域的。理想情况下我们可以配置一个根的密钥就够了，但是目前还没有完全布署的情况下，我们需要配置很多安全岛（）的密钥。可以从很多公开的网站下载这些可信域的文件，包括：
（1）Root ZoneTrust ：。2010年7月布署实施。如果全部布署成功，这一个公开密钥就足够了。
（2）The UCLA：，由美国加州大学洛杉矶分校（UCLA）张丽霞教授的实验室维护。
（3）The IKS Jena TAR：
这些文件大概是这样的格式：
-keys {
“.” 256 3 5 “…
……
….==”;
“193.in-addr.arpa.” 257 3 5 “…
….=”;
};
假设上述trust 的文件为/var/named/trust-.conf，则在/etc/named.conf中增加下面一行：
“/var/named/sec-trust-.conf”;
3.1.3 测试
在完成上述配置修改之后重新启动named进程，然后选择一个trust 文件中有的区或者它下一级的域名，在解析服务器上用dig测试一下，例如：
#dig @127.0.0.1 + . SOA
如果配置正确，应该返回的SOA记录和相应的RRSIG记录，另外返回的头部中应该包含AD标志位，表示相关的数字签名验证是正确的，类似下面的样子：
;; ->>

文章插图
# cat “$ .+005+03674.key” >>
然后执行签名操作：
# - -o .
.
上面的-o选项指定代签名区的名字。生成的.
然后修改/etc/named.conf如下：
{
“/var/named”;
- yes;
};
zone “” {
type ;
file “.”;
};
记住，你每次修改区中的数据时，都要重新签名：
# - -o-f ..new .
# mv . ..bak
# mv ..new .
# rndc
3.2.3 发布公钥
要让其他人验证你的数字签名，其他人必须有一个可靠的途径获得你的公开密钥。通过上一级域名服务器数字签名的方式签发你的公钥。