查看“DNSSEC流程精读”的源代码


= '''用途''' =
1、数据来源验证

2、数据完整性保护

DNSSEC 并非对 DNS 查询和响应本身进行加密签名，而是由数据所有者对 DNS 数据自身进行签名。

= 涉及到的记录类型 =
{| class="wikitable"
|'''名称'''
|'''作用'''
|'''备注'''
|-
|普通记录
|给客户端查询使用
|包含A、NS、CNAME等普通解析记录
|-
|dnskey:zsk(zone sign key)
|给zone里面的普通记录签名的密钥对
|非对称加密的双密钥，暴露在外面的公钥叫做dnskey
|-
|dnskey:ksk(key sign key)
|给zsk签名的密钥对
|
|-
|DS
|ksk公钥的摘要
|这玩意一般是下级的DS存在上级，作为普通记录的一部分
|}

= 随手画个图 =

=== 流程： ===
说明，此处假设：

根区域文件包含了com，net等顶级域的解析授权信息，该文件存放在根区服务器；

com，net等顶级区域文件，包含了a.com等次级域的解析授权信息，该文件存放在顶级权威服务器。


'''''需要清楚的是'''''，

实际情况上，a.com等次级域的解析授权信息，还会存在顶级权威服务器的下一级授权服务器中，原因尚未了解清楚（例如deadfishcrypto.com是被授权到dns15里面去了）。

这里为了简化，就把a.com的解析信息存放在了权威服务器中的com区域文件中去了。
[[文件:Dnssec流程精读-image-01.png|居中|有框]]





解析验证流程

关于信用锚的数据格式，引用一段话：

4.6.6. 了解信任锚（Trust Anchor） 信任锚由 `DNS` 域名以及此域名相关的公用密钥（或公用密钥的散列值）组成。 其表述为一个基本的 64 比特加密密钥。 其类似于一种信息交换方式的证书，含有公用密钥， 可用于对 `DNS` 记录进行核实和身份验证。 

原文参考：<nowiki>https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/7/html/security_guide/sec-securing_dns_traffic_with_dnssec</nowiki>

=== 数据结构： ===
标识：

红色：外部理应能够直接获取的数据

黑色：外部不需要知道的数据

蓝色：官方发布的数据

[[文件:DNSSEC流程精读-Image-02.png|居中|有框]]



数据之间的关系

=== 信任链： ===
这里的信任大前提就是：递归服务器上的信任锚是绝对可信的。

[[文件:DNSSEC流程精读-Image-03.png|居中|有框]]



信任链

= 结论 =
由此可见，DNSSEC的信任流程是从递归服务器的信任锚开始的，如文章开头所说，DNSSEC并不保证 '''''非数据所有者''''' 的信息是否具备真实性。也就是说递归服务器和客户端之间的数据真实性问题，DNSSEC并不负责。