DNSSEC流程精读 - 版本历史

2024年4月28日 (日) 12:22 Admin

2024-04-28T12:22:13Z

←上一版本		2024年4月28日 (日) 20:22的版本
第39行：		第39行：
	com，net等顶级区域文件，包含了a.com等次级域的解析授权信息，该文件存放在顶级权威服务器。		com，net等顶级区域文件，包含了a.com等次级域的解析授权信息，该文件存放在顶级权威服务器。

	'''''需要清楚的是'''''~~，实际情况上，a~~.com等次级域的解析授权信息，还会存在顶级权威服务器的下一级授权服务器中，原因尚未了解清楚（例如deadfishcrypto.~~com是被授权到dns15里面去了）。这里为了简化，就把a~~.com的解析信息存放在了权威服务器中的com区域文件中去了。
			'''''需要清楚的是'''''，

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

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

第62行：		第67行：

	蓝色：官方发布的数据		蓝色：官方发布的数据

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



	数据之间的关系		数据之间的关系
第67行：		第76行：
	=== 信任链： ===		=== 信任链： ===
	这里的信任大前提就是：递归服务器上的信任锚是绝对可信的。		这里的信任大前提就是：递归服务器上的信任锚是绝对可信的。

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



	信任链		信任链

2024年4月28日 (日) 12:19 Admin

2024-04-28T12:19:14Z

←上一版本		2024年4月28日 (日) 20:19的版本
第40行：		第40行：

	'''''需要清楚的是'''''，实际情况上，a.com等次级域的解析授权信息，还会存在顶级权威服务器的下一级授权服务器中，原因尚未了解清楚（例如deadfishcrypto.com是被授权到dns15里面去了）。这里为了简化，就把a.com的解析信息存放在了权威服务器中的com区域文件中去了。		'''''需要清楚的是'''''，实际情况上，a.com等次级域的解析授权信息，还会存在顶级权威服务器的下一级授权服务器中，原因尚未了解清楚（例如deadfishcrypto.com是被授权到dns15里面去了）。这里为了简化，就把a.com的解析信息存放在了权威服务器中的com区域文件中去了。
			[[文件:Dnssec流程精读-image-01.png\|居中\|有框]]





	解析验证流程		解析验证流程

2024年4月28日 (日) 12:17 Admin

2024-04-28T12:17:12Z

←上一版本		2024年4月28日 (日) 20:17的版本
第1行：		第1行：

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

Admin：创建页面，内容为“ = 用途 = 1、数据来源验证 2、数据完整性保护 DNSSEC 并非对 DNS 查询和响应本身进行加密签名，而是由数据所有者对 DNS 数据自身进行签名。 = 涉及到的记录类型 = {| class="wikitable" |'''名称''' |'''作用''' |'''备注''' |- |普通记录 |给客户端查询使用 |包含A、NS、CNAME等普通解析记录 |- |dnskey:zsk(zone sign key) |给zone里面的普通记录签名的密钥对 |非对称加密的双…”

2024-04-28T12:16:05Z

创建页面，内容为“ = 用途 = 1、数据来源验证 2、数据完整性保护 DNSSEC 并非对 DNS 查询和响应本身进行加密签名，而是由数据所有者对 DNS 数据自身进行签名。 = 涉及到的记录类型 = {| class="wikitable" |'''名称''' |'''作用''' |'''备注''' |- |普通记录 |给客户端查询使用 |包含A、NS、CNAME等普通解析记录 |- |dnskey:zsk(zone sign key) |给zone里面的普通记录签名的密钥对 |非对称加密的双…”

新页面

= 用途 =
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区域文件中去了。

解析验证流程

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

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