| 章 | 节 | 标题 | 说明 | 补充说明 | 支持级别 |
| 1 | 介绍 | 1、定义DNSSEC协议修改点 2、定义以下概念：已签名域（signed zone）和域签名的要求列表 3、描述权威域名服务器为了处理签名域的行为变化 4、描述了包括解析器在内的实体的行为 5、描述了怎样使用DNSSEC RRs去认证一个应答 |
NA | ||
| 2 | 域签名 | 介绍五种资源记录类型和签名域概念 1、DNSKEY 2、RRSIG 3、NSEC 4、DS 5、CNAME |
需要结合rfc4034一起看 | ||
| 2.1 | 包含DNSKEY的域 | ||||
| 2.2 | 包含RRSIG的域 | ||||
| 2.3 | 包含NSEC的域 | ||||
| 2.4 | 包含DS的域 | ||||
| 2.5 | CNAME资源记录的变化 | ||||
| 2.6 | 出现在域分片的DNSSEC类型 | ||||
| 3 | 命名服务器功能 | ||||
| 4 | 解析器功能 | ||||
| 4.1 | 支持EDNS | 1、解析器发送查询报文时，消息头必须支持DO比特位。 | MUST | ||
| 2、解析器必须支持最少1220字节的消息。（以前为512字节） | MUST | ||||
| 3、解析器支持应该支持4000字节的消息。 | SHOULD | ||||
| 4、解析器的IP层必须能处理UDP分片报文。 | MUST | ||||
| 4.2 | 支持签名认证 | 1、解析器必须支持签名认证。 | MUST | ||
| 2、解析器应该对每一个收到的应答应用第五章描述的签名认证机制。除了以下情况： （1）解析器是递归命名服务器的一部分 （2）应答结果告知解析器不要让这个查询结果有效或者这个查询的有效性受限于本地策略。 |
SHOULD | ||||
| 3、解析器支持的签名认证必须包括通配符主机名认证。 | MUST | ||||
| 4、解析器可以尝试让非安全记录生效，但是要声明这个接收到的应答不充分可靠。 | MAY | ||||
| 5、尝试检索丢失的NSEC时，必须向服务器查找父域而不是子域。 | 定位父域NS(权威服务器) RRset算法：从授权名开始，每次用最左边的名字去查找，遍历树结构，直到找到NS或者遍历完整棵树，过程结束。 | MUST | |||
| 6、尝试检索丢失的DS时，必须向服务器查找父域而不是子域。 | MUST | ||||
| 4.3 | 辨识数据的安全状态 | 必须能够辨识四种场景 | MUST | ||
| 1、secure场景：解析器能通过信任锚构建一个DNSKEY和DS的信任链。 处理：RRset应该被签名并受限于签名有效性。 |
MUST | ||||
| 2、Insecure场景：通过已配置的任一信任锚都无法对资源记录构建成DNSKEY和DS的信任链。 处理：RRset是否有签名都可以，但是解析器不能认证签名。 |
MUST | ||||
| 3、Bogus场景：解析器认为可以构建信任链，而实际构建不了（可能是某些原因导致签名失效或相关DNS安全RR数据丢失）。 处理：可能意味着遇到DNS攻击，也可能是配置错误或数据冲突。 |
MUST | ||||
| 4、Indeterminate场景：无法判断RRset是否应该签名（无法获得必要的DNSSEC RRs）。 处理：这种情况发生于解析器找不到识别相关域的安全服务器。 |
MUST | ||||
| 4.4 | 配置信任锚 | 1、解析器必须能配置至少一个信任锚（DNSKEY或DS）。 | MUST | ||
| 2、解析器应该支持配置多个信任锚。 | SHOULD | ||||
| 3、若没有配置信任锚，不应该使签名有效。 | SHOULD | ||||
| 4、解析器应该有合理机制在它启动时获得信任锚。 | 可以从很多公开的网站下载这些可信域的DNSKEY文件，包括： （1）Root Zone DNSSEC Trust Anchors：https://www.iana.org/dnssec/。2010年7月布署实施。如果DNSSEC全部布署成功，这一个公开密钥就足够了。 （2）The UCLA secspider ： https://secspider.cs.ucla.edu，由美国加州大学洛杉矶分校（UCLA）张丽霞教授的实验室维护。 （3）The IKS Jena TAR：https://www.iks-jena.de/leistungen/dnssec.php |
SHOULD | |||
| 4.5 | 应答缓存 | 1、解析器应当能够缓存完整应答，包括命名记录和任意DNSSEC相关的资源记录。 | SHOULD | ||
| 2、解析器应该在记录有效期满后丢弃缓存记录。 | SHOULD | ||||
| 4.6 | 处理CD、AD比特位 | 1、解析器可以在查询报文中设置CD比特位。 | CD比特位有效意味着收到的相应应答中无论认证的本地策略是什么，解析器都愿意负责。 | MAY | |
| 2、解析器必须在封装查询报文时清空AD比特位，以防止那些不理解查询消息的服务器盲目拷贝消息头。 | MUST | ||||
| 3、解析器如果不是安全环境下，必须忽视应答报文中的CD和AD比特位；或者解析器指定配置要求在非安全环境下仍要关注消息头比特位。 | MUST | ||||
| 4.7 | 缓存错误数据 | 为了预防不必要的DNS阻塞，解析器可以限制性的缓存无效签名。 | MAY | ||
| 解析器不可以从错误数据缓存中返回资源记录，除非解析器不要求使签名生效。 | MUST | ||||
| 4.8 | 综合的CNAME记录 | 解析器必须要支持处理已签名的CNAME记录。 | MUST | ||
| 4.9 | 末梢解析器 | 略 | NA |
本文转自静默虚空博客园博客，原文链接：http://www.cnblogs.com/jingmoxukong/p/3571877.html，如需转载请自行联系原作者
