人为因素与 DNSSec

　　现在我们首先讨论一下实施。DNSSec的首次实施发生在1999年的BIND 8中，几乎无法使用。首次签署域错综复杂，犹如拜占庭工程，要求多个命令行工具-- dnssec-keygen, dnssec-signzone等等，每个命令行都有不同理解，几个或十几个命令行选项与选项参数。你运行这些，他们创建文件，你将这些文件添加到原有的域数据文件中，你又要去运行其他工具。

　　任何时候只要修改过域名甚至没有修改过但是签名快到期时都要重新签署，你不得不运行命令行工具再次签署。命令行工具重新生成该域名内的所有签名，即使你只修改了一个记录。

　　好消息是互联网系统协会及供应商(包括Infoblox在内)已投入大量精力简化与自动化这些流程。现在你只需在GUI内一键确认(点击几次)便可签署域名，或者借助rndc签署域名，而且域名的维护也可以自动进行。然而，可能是很多管理员对之前恐怖的手动过程仍心有余悸吧。

　　导致DNSSec发展缓慢的另一人为因素是不确定性，这是由域名服务器的一些执行者和一些DNS管理员造成的。首次描述DNSSec的RFC 2065出版于1997年1月。实施该标准的过程中又产生了DNSSec的修改版，这在1999年3月出版的RFC2535中有描述。然而，体验再次证明该版本对于管理一个像Internet一样大的网络是不实际的。这引起了DNSSec的新增变化，也就是2005年3月出版的RFC 4033至4035。

　　这些修正还是不充分。隐私权拥护者认为DNSSec签署的域名容易通过“假域名转移”使其内容泄露，一些注册机构(运行.com等优异域名的组织机构)认为将签名添加到其域名中NS记录的每一集群中将极其繁琐和麻烦。因此，介绍另一全新DNSSec记录类型NSEC3的RFC5155于2008年3月应运而生。

　　历史细节固然重要，但更重要的是DNSSec从1997年到2008年改变了很多，它开始瞄准域名服务器实施人员和DNS管理员。可以理解，部分人会选择推迟添加DNSSec支持其域名服务器或签署其域名，他们等待一切尘埃落定。

　　现在已经到了2014年，一切基本都已就绪，每个主要域名服务器实施，从BIND到微软DNS服务器，再到NSD和Unbound等新来者都支持DNSSec。因此，是时候行动起来了。