DNSSEC流程精读

用途

1、数据来源验证

2、数据完整性保护

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

涉及到的记录类型

名称	作用	备注
普通记录	给客户端查询使用	包含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区域文件中去了。

解析验证流程

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

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

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

数据结构：

标识：

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

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

蓝色：官方发布的数据

数据之间的关系

信任链：

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

信任链

结论

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