| 章 | 节 | 标题 | 说明 | 补充说明 | 支持级别 |
| 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 |
RFC4035笔记
2014-02-27
911
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《
阿里云开发者社区用户服务协议》和
《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写
侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：
章
节
标题
说明
补充说明
支持级别
1
介绍
1、定义DNSSEC协议修改点2、定义以下概念：已签名域（signed zone）和域签名的要求列表3、描述权威域名服务器为了处理签名域的行为变化4、描述了包括解析器在内的实体的行为5、描述了怎样使用DN...
目录
相关文章
|
3月前
用MASM32按Time Protocol（RFC868）协议编写网络对时程序中的一些有用的函数代码
用MASM32按Time Protocol（RFC868）协议编写网络对时程序中的一些有用的函数代码
47
2
2
|
4月前
|
XML
存储
网络安全
|
4月前
|
传感器
XML
编解码
|
4月前
|
存储
|
4月前
|
传感器
|
7月前
|
安全
网络虚拟化
数据安全/隐私保护
|
7月前
|
C++
常用日期和时间标准对比：HTML, ISO 8601, RFC 3339, RFC 5322
日期和时间，对于不同系统和平台之间的数据交换和互操作至关重要。本文将对比 HTML 标准、ISO 8601、RFC 3339 和 RFC 5322，为读者提供参考。
111
0
0
|
7月前
|
存储
监控
安全
RFC 系列文档和 RFC 编辑器的相关说明
第一个征求意见 (Request for Comments，RFC) 文档于 1969 年 4 月发布，作为设计和构建我们现在所知的互联网的努力的一部分。从那时起，RFC 系列一直是致力于记录 Internet 技术规范的档案系列，包括 Internet 研究和工程社区的一般贡献以及标准文档。
599
0
0
热门文章
最新文章
1
Gitlab----使用Docker方式安装部署Gitlab
2
Mac搭建安卓模拟器（支持M1/M2/M3/M4）
3
java报错javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException
4
开发人员各级岗位胜任力模型
5
Hive之数据倾斜的原因和解决方法
6
【Java】留下没有基础眼泪的面试题
7
iptables系列教程（二）| iptables语法规则
8
13.4. 临时表是否需要建索引
9
共享的两种方式
10
Andriod动态布局
1
Linux 各发行版安装 ping 命令指南
42
2
Linux缓存管理：如何安全地清理系统缓存
101
3
《CMake：掌控 C++人工智能项目编译的魔法棒》
35
4
《C++人工智能开发 IDE 全解析：助力智能创新之路》
37
5
《解锁 Eigen 库在 C++人工智能项目中的潜能与优化之道》
35
6
《解析 MXNet 的 C++版本在分布式训练中的机遇与挑战》
24
7
《探索 Caffe2 的 C++接口在移动设备上的性能优化之路》
27
8
docker高级篇（大厂进阶）：安装redis集群
45
9
Lyra：SmartMore 联合香港多所高校推出的多模态大型语言模型，专注于提升语音、视觉和语言模态的交互能力
63
10
LatentLM：微软联合清华大学推出的多模态生成模型，能够统一处理和生成图像、文本、音频和语音合成
48