用途

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并不负责。