DNSSEC 原理、配置与布署简介( 五 ) _签名

（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 发布公钥
要让其他人验证你的数字签名，其他人必须有一个可靠的途径获得你的公开密钥。通过上一级域名服务器数字签名的方式签发你的公钥。
用-时，会自动生成-文件和dsset-开头的两个文件，分别存储着KSK的记录和DS记录。作为区的管理员，你需要把这两个文件发送给.net的管理员， .net的管理员需要把这两条记录增加到.net区中，并且用.net的密钥重新签名。
. 86400 IN NS .
86400 DS 15480 5 1 (
6C17 )
86400 RRSIG DS 5 2(
234 23912 net.
……
= )
如果你的上一级域名服务器还没有配置，你不得不另找其他方式了，比如，把上述两个文件提交到一些公开的trust 数据库中发布(如上面介绍过的) ，或者直接交给愿意相信你的解析服务器的管理员，配置到他们的trust 文件中。
4 的布署
互联网工程技术领域普遍认为是增强互联网基础设施安全非常关键的一步，比如，美国国土安全部发起了布署计划，美国网络空间国家战略安全明确要求布署。的大规模布署还可能解决其他的安全问题，比如密钥的分发和安全的电子邮件。
尽管互联网工程界认为非常重要，但是大规模的布署仍然非常谨慎。巴西 (.br)、保加利亚 (.bg)、捷克 (.cz)、波多黎各 (.pr) 和瑞典 (.se), 很早就开始了在他们国家的顶级域名上布署， IANA在2007年开始在一个根域名服务器上进行签名试验。许多机构在的布署上付出了巨大的努力，具体请参见[9] 。
在ICANN和的推动下， 2010年7月所有13个根域名服务器都用对根域签名完毕且投入运营[10] 。顶级域名（如.org, .net等）也在计划之中，有些国家级的顶级域名服务器（如.cz、.jp、.us、.fr等）已经完成了这一任务。
国际上一些大的ISP已经开始布署支持的解析服务器，以保护他们接入用户的安全，美国公司是其中的先驱者之一。