DNSSEC对现有DNS协议的修改

　　由于新增DNS资源记录的尺寸问题，支持DN S SE C 的域名服务器必须支持EDNS0(RFC2671)，即允许DNS报文大小必须达到1220字节(而不是最初的512字节)，甚至可以是4096字节。

　　DNSSEC在报文头中增加了三个标志位：

　　(1)DO(DNSSEC OK, 参见RFC3225)：支持DNSSEC的解析服务器在它的DNS查询报文中，必须把DO标志位置1，否则权威域服务器认为解析器不支持DNSSEC就不会返回RRSIG等记录。

　　(2)AD (Authentic Data)：AD是认证数据标志，如果服务器验证了DNSSEC相关的数字签名，则置AD位为1，否则为0。这一标志位一般用于自己不做验证的解析器(non-validating security-aware resolvers)和它所信任的递归解析服务器(securi tyaware recursive name server)之间，用户计算机上的解析器自己不去验证数字签名，递归服务器给它一个AD标志为1的响应，它就接受验证结果。这种场景只有在它们之间的通信链路比较安全的情况下才安全，比如使用了IPSEC和TSIG。

　　(3)CD (Checking Disabled)： 关闭检查标志位用于支持DNSSEC验证功能的解析器(validating security-aware resolver)和递归域名服务器之间，解析器在发送请求时把CD位置1，服务器就不再进行数字签名的验证而把递归查询得到的结果直接交给解析器，由解析器自己验证签名的合法性。

　　最后，支持验证的DNSSEC 解析器对它所收到的资源记录的签名(RRSIG)，必须能够区分以下四种结果：

　　(1)安全的(secure)：解析器能够建立到达资源记录签名者的信任链，并且可以验证数字签名的结果是正确的。

　　(2)不安全的(insecure)：解析器收到了一个资源记录和它的签名，但是它没有到达签名者的信任链，因而无法验证。

　　(3)伪造的(Bogus)：解析器有一个到资源记录签名者的信任链，但是签名验证是错的。可能是因为受到攻击了，也可能是管理员配置错误。

　　(4)不确定(Indeterminate)：解析器无法获得足够的DNSSEC 资源记录，因而不能确定用户所请求的资源记录是否应该签名。(待续)

　　(作者单位为清华大学信息网络工程研究中心)