DNSSEC

DNSSEC 不保护整个 DNS 系统的原因：

DNSSEC（Domain Name System Security Extensions）是为 DNS（域名系统）增加的一种安全扩展，旨在提高 DNS 响应的安全性和防篡改能力。然而，DNSSEC 并不提供全面的保护。以下是对该问题的详细分析：

1. DNSSEC 仅保护数据完整性和真实性

• 核心功能：

  DNSSEC 主要通过数字签名来验证 DNS 响应的真实性和完整性。具体来说：

  • 来源认证： 确保 DNS 数据来自合法的权威服务器。
  • 完整性验证： 确保 DNS 数据在传输过程中未被篡改。

• 不加密数据： DNSSEC 并不会加密 DNS 查询或响应，它只是通过签名保证数据的完整性。因此，数据仍然是明文传输的，可能被窃听。

• 不防范隐私泄漏： 例如，DNS-over-HTTPS（DoH）是为了避免 DNS 查询暴露隐私，而 DNSSEC 并没有提供类似的保护。

2. DNSSEC 不保护查询过程

• 保护响应，但不保护查询： DNSSEC 的保护仅限于验证 DNS 响应的真实性。它不防范查询过程中的攻击（如中间人攻击、流量重定向等）。
• 查询过程中的攻击： 在用户发送查询请求到递归服务器时，DNSSEC 无法防止 DNS 查询劫持或干扰。查询可能被篡改或被恶意重定向，导致攻击者获取用户的信息或让用户访问恶意网站。

3. 仅限于签名域名

• 保护范围有限： DNSSEC 只能保护那些已经启用 DNSSEC 并正确配置签名的域名。若域名没有启用 DNSSEC，它将无法得到保护。
• 缓存投毒攻击： 在 DNSSEC 未启用的域名中，仍然可能发生缓存投毒攻击（Cache Poisoning），即恶意的 DNS 响应被递归服务器缓存，造成错误的解析结果。

4. 依赖递归服务器和权威服务器支持

• 递归服务器的实现： DNSSEC 的有效性依赖于递归解析器（用户请求 DNS 查询的服务器）是否启用了 DNSSEC 验证。如果递归解析器没有启用 DNSSEC 验证，它就无法验证 DNS 响应的数字签名。
• 权威服务器的配置： DNSSEC 还依赖于权威服务器正确配置签名。如果权威服务器没有正确配置签名，DNSSEC 也无法提供保护。

5. 无法防范内部威胁

• 假设安全的权威服务器： DNSSEC 假设权威服务器是安全的，且签名密钥没有泄露。如果权威服务器被攻破或签名密钥泄露，DNSSEC 将无法提供保护。
• 信任问题： DNSSEC 本身依赖于对权威服务器的信任。如果攻击者能够入侵权威服务器或者泄露密钥，那么即使启用了 DNSSEC，攻击者仍然能够伪造有效的 DNS 响应。

---

总结：

DNSSEC 主要解决的是 DNS 响应数据的真实性和完整性问题，确保数据没有被篡改或伪造。然而，它并不能解决以下问题：

1. 查询过程中的攻击：如中间人攻击、流量重定向等。
2. 隐私泄露问题：DNS 数据是明文传输的，容易被窃听，DNSSEC 不提供加密。
3. 未启用 DNSSEC 的域名：只有已经启用 DNSSEC 的域名才会得到保护，未启用的域名易受攻击。
4. 依赖于递归解析器和权威服务器的正确配置：若这些服务器没有正确实现和配置 DNSSEC，保护就无法生效。
5. 内部威胁：如果权威服务器或签名密钥遭到泄露，DNSSEC 无法保护用户免受损害。

因此，虽然 DNSSEC 提高了 DNS 的安全性，但它并不能全方位保护整个 DNS 系统，仍然有很多漏洞和安全隐患。

为什么DNSSEC 的推广速度相对较慢

主要与技术复杂性、兼容性问题和性能问题有关。以下是详细的分析和解释：

---

1. 复杂性与实施成本

(1) 技术复杂性

• 数字签名管理：
  • 每个 DNS 记录需要生成数字签名。
  • 需要管理多种密钥，如：
    • KSK（Key Signing Key）：用于签名 ZSK 的公钥。
    • ZSK（Zone Signing Key）：用于签名具体的 DNS 记录。
  • 这些密钥必须定期轮换，增加了密钥管理的复杂性。
• 操作负担：
  • 对于管理大量域名或记录的管理员，生成、配置和维护这些签名是一项繁琐的任务。
  • 错误配置可能导致 DNS 服务中断或验证失败。

(2) 部署成本

• 服务器升级：
  • 组织需要更新其现有 DNS 服务器以支持 DNSSEC。
  • 需要额外的技术人员或第三方服务来设置和维护 DNSSEC。
• 密钥管理安全：
  • 确保私钥的安全性，防止泄露。
  • 配置失误可能会导致域名不可用。
• 中小型组织的压力：
  • 对于资源有限的小型企业，实施和维护 DNSSEC 的成本可能显得过高。
  • 许多组织选择延后或放弃实施 DNSSEC。

---

2. 兼容性问题

(1) 现有系统的兼容性

• 基础设施升级需求：
  • 很多现有的 DNS 系统（服务器硬件、操作系统、管理工具）并不完全支持 DNSSEC。
  • 实施 DNSSEC 可能需要更换现有的硬件或软件，这对大型组织而言成本非常高。
• 旧系统限制：
  • 一些老旧的 DNS 系统没有能力处理 DNSSEC 的签名验证逻辑，导致无法实现无缝集成。

(2) 客户端的兼容性

• 设备和软件支持不足：
  • 一些旧设备或嵌入式系统（如老款路由器、IoT 设备）可能不支持 DNSSEC。
  • 即使在现代设备中，某些客户端应用程序也可能忽略 DNSSEC 验证结果。
• 全球推广难度：
  • 由于用户终端设备兼容性参差不齐，DNSSEC 的全面推广受限。

---

3. 性能问题

(1) 额外的计算开销

• 查询和验证：
  • DNSSEC 增加了查询过程的复杂性，需要解析器验证 DNS 响应的签名。
  • 验证签名会消耗 CPU 和内存资源，尤其是递归解析器需要对每次查询执行验证。
• 响应延迟：
  • 增加的计算和验证步骤可能导致响应时间延迟。
  • 在需要高性能和低延迟的环境（如内容分发网络、实时应用）中，延迟可能显得尤为明显。

(2) 传输数据的增加

• 消息大小：
  • DNSSEC 增加了 DNS 响应中的签名数据和公钥信息，使得 DNS 消息变得更大。
• 带宽压力：
  • 签名和验证信息的增加会导致网络传输负担加重。
  • 在带宽有限的网络中，可能导致查询失败或速度显著降低。
• 高流量环境的挑战：
  • 例如，域名解析流量巨大的网络服务提供商可能需要额外的硬件支持来应对更大的数据流量和计算需求。

---

总结

DNSSEC 推广慢的主要原因：

1. 复杂性与高成本：
   • 配置和管理 DNSSEC 需要较高的技术水平和投入，特别是对密钥管理和基础设施升级的要求。
2. 兼容性问题：
   • 现有的 DNS 基础设施和客户端设备支持不足，导致部署存在障碍。
3. 性能影响：
   • DNSSEC 增加了计算开销和传输数据量，在高流量或带宽有限的环境中表现尤为明显。

如何加速 DNSSEC 的推广？

• 推动自动化工具和简化配置流程，降低部署复杂性。
• 增加对 DNSSEC 的支持和教育，提升组织的意识和能力。
• 与其他安全技术（如 DoH、DoT）结合，进一步提高 DNS 的整体安全性和隐私保护水平。

DNSSEC（Domain Name System Security Extensions）是对 DNS 系统的安全扩展，旨在提供数据的完整性和真实性。为了实现这一点，DNSSEC 引入了一些特定的 DNS 记录类型和术语，用于密钥管理、签名、验证等功能。以下是 DNSSEC 相关的主要 DNS 记录类型和术语的详细解释：

DNSSEC 相关 DNS 记录类型和术语

类型	中文	用途
DS 记录	委托签名者记录	- 用于在父区域和子区域之间建立安全的信任链。 - DS 记录存储一个 DNSKEY 记录的加密哈希。 - 它将父域与子域的公钥联系起来，确保子域的 DNSSEC 签名能被父域信任。
DNSKEY 记录	DNSSEC 密钥	- 存储与特定 DNS 区域（Zone）关联的公钥。 - 这些公钥用于验证域名的数字签名。 - 确保 DNS 数据在传输过程中未被篡改，并验证响应数据的真实性和完整性。
RRSIG 记录	资源记录签名记录	- 包含与一组 DNS 资源记录（RRset）关联的加密签名。 - 签名由域名的私钥生成，用于验证 RRset 是否被篡改。 - 通过验证 RRSIG 记录，解析器可以确保 DNS 数据的完整性。
RRset	资源记录集	- 与 DNS 中的特定名称关联的特定类型的所有资源记录的集合。 - 例如，example.com 的 A 记录集合可能包含该域的所有 IP 地址记录。
Zone Signing Key (ZSK)	区域签名密钥	- ZSK 是公钥/私钥对，用于对资源记录集（RRset）进行签名和验证。 - 区域签名密钥的作用是确保该区域内的 DNS 数据（例如 A、MX 记录等）没有被篡改。
Key Signing Key (KSK)	密钥签名密钥	- KSK 也是公钥/私钥对，用于签名 DNS 区域的公钥（即 DNSKEY 记录）。 - 它的作用是验证公共区签名密钥（DNSKEY）没有泄露或被篡改。 - KSK 主要用于父区与子区之间的信任链的建立（通过 DS 记录）。

各记录的详细用途解释：

1. DS 记录（委托签名者记录）

• DS 记录用于建立 DNSSEC 中的 信任链，它在父区和子区之间建立安全链接。每个 DS 记录包含父区验证子区公钥的哈希值。它确保了如果子区的 DNS 数据被篡改，父区能够发现并拒绝不一致的响应。

2. DNSKEY 记录（DNSSEC 密钥）

• DNSKEY 记录用于存储与 DNS 区域相关的公钥。这些密钥是 DNSSEC 验证过程中的核心，通过它们来验证来自该区域的 RRSIG 记录。每个 DNS 区域至少有一个 DNSKEY 记录，它包含区域的公钥，用于验证签名的资源记录（RRset）。

3. RRSIG 记录（资源记录签名记录）

• RRSIG 记录是 DNSSEC 中重要的一部分，它为资源记录（如 A 记录、MX 记录等）提供签名。每个 RRSIG 记录都与一个特定的资源记录集（RRset）相关联，并且签名由该区域的私钥生成。解析器使用 DNSKEY 记录中的公钥来验证这些签名，从而确认资源记录是否被篡改。

4. RRset（资源记录集）

• RRset 是一组特定类型的 DNS 记录，如 A 记录集、MX 记录集等。这些记录对于某个域名有着相同的类型，并且在 DNS 查询中被返回。DNSSEC 通过对这些记录集合进行签名来保证其内容的完整性。

5. Zone Signing Key (ZSK)（区域签名密钥）

• 区域签名密钥用于对每个 DNS 区域的资源记录（RRset）进行签名。ZSK 的使用是 DNSSEC 中确保 DNS 数据不被篡改的基本机制。ZSK 一般较为频繁地更新，以增强密钥管理的安全性。

6. Key Signing Key (KSK)（密钥签名密钥）

• KSK 是 DNSSEC 中的另一对公钥/私钥，它用于签名 DNS 区域的公钥（DNSKEY 记录）。它主要用于建立父区和子区之间的信任链。例如，父区会通过 DS 记录验证子区的 KSK 是否有效，并且通过验证 KSK 来保证子区的 DNSKEY 记录的安全性。

---

总结

DNSSEC 使用这些记录和术语来保障 DNS 数据的完整性和真实性，防止数据在传输过程中被篡改。每种记录在 DNSSEC 中有其特定的作用，从 DS 记录（建立信任链）到 DNSKEY 记录（存储公钥用于验证签名），再到 RRSIG 记录（验证 DNS 数据完整性）和 KSK、ZSK（管理签名密钥）。这些机制共同工作，确保 DNS 系统能够抵御篡改、伪造和其他恶意攻击。

Zone签名方法与信任链

为什么父zone的ZSK对子zone的KSK的DS签名

这个问题涉及到DNSSEC（DNS安全扩展）中的密钥管理和信任链的构建。要理解这个问题，我们首先需要知道父zone、子zone、KSK、ZSK以及DS记录的含义。

• 父zone：是指上级域名区域，负责将查询请求传递给子域。例如，com是example.com的父zone。
• 子zone：是父zone的下级区域，负责管理和签名其下的DNS数据。例如，example.com是com的子zone。
• KSK（Key Signing Key）：用于签署子zone的密钥，确保父zone和子zone的信任关系。
• ZSK（Zone Signing Key）：用于签署该zone内的数据记录，例如A记录、MX记录等。
• DS（Delegation Signer）记录：父zone中的记录，指向子zone的KSK，用于建立父子zone之间的信任链。

1. 子zone更换ZSK时无需通知父zone

子zone内的ZSK用于签署子zone内的资源记录（如DNS数据）。ZSK是频繁更新的，因为它直接用于签署数据记录。因此，在子zone更新ZSK时，并不需要通知父zone。这是因为父zone的DS记录是指向子zone的KSK，而不是ZSK。KSK相对较少变动，且父zone只需要关注KSK的有效性即可。

2. 父zone更换密钥时无需通知子zone

在DNSSEC中，父zone的ZSK用于签署子zone的DS记录。这些DS记录中存储的是子zone的KSK的哈希值，而非直接存储子zone的KSK本身。这样，即使父zone更新了它的ZSK，重新签署了DS记录，也不需要通知子zone。这是因为子zone的KSK没有变化，而父zone只需要重新签署子zone的DS记录以保持信任链的有效性。

这种设计使得DNSSEC在管理和扩展上具有可扩展性，因为父子zone之间的交互可以尽量减少，避免了频繁的更新和沟通。

3. 信任链：DNSKEY -> [DS -> DNSKEY]* -> RRset

在DNSSEC中，信任链的构建是至关重要的。信任链的核心思想是，通过父zone的DS记录和子zone的DNSKEY记录，逐步验证一个域名的DNS记录的真实性。具体过程如下：

• DNSKEY：每个zone有一个DNSKEY记录，包含其公钥（KSK和ZSK）。
• DS记录：父zone中的DS记录指向子zone的KSK，确保父zone信任子zone。
• RRset（Resource Record Set）：存储实际的DNS数据记录，如A记录、MX记录等。通过这些记录，客户端可以获取有关域名的详细信息。

通过这种结构，验证过程如下：

1. 客户端从根域（最顶层的父zone）开始，验证根域的DNSKEY。
2. 通过父zone的DS记录验证子zone的KSK的真实性。
3. 在子zone内使用KSK验证ZSK的有效性。
4. 最终，使用ZSK来验证子zone中各个DNS数据记录（如A记录、MX记录等）。

总结

• 可扩展性：通过将KSK和ZSK分离，父zone和子zone之间的密钥管理可以独立进行，这使得更换密钥时不需要频繁通知对方。例如，子zone更换ZSK时，父zone无需知道；父zone更换密钥时，子zone也不需要重新进行配置。
• DS记录的作用：父zone签署子zone的KSK的哈希值，并将其作为DS记录保存在父zone中，这确保了父zone能够验证子zone的KSK，从而建立信任链。

如何安全地获得公钥？

问题：公钥是验证签名的核心，接收者必须确保获得的公钥确实属于签名者。如果公钥被篡改（如中间人攻击），攻击者可以伪造签名。

解决方法：

1. 通过可信的CA（证书颁发机构）获取公钥：

   • 使用

     PKI（公钥基础设施）：

     • CA为公钥签发数字证书，证书绑定签名者的身份和公钥。
     • 验证时，接收者验证CA的签名，以确认公钥的真实性。

   • 示例：HTTPS中通过SSL/TLS证书验证服务器的公钥。

2. 使用预共享的可信渠道：

   • 在签名者与接收者之间建立安全的初始信任，比如线下分发或预共享。
   • 例如，在某些闭环系统中，公钥可通过安全的物理渠道分发。

3. 利用Web of Trust（信任网）：

   • 通过一组可信任的第三方间接验证公钥的真实性。
   • 常见于PGP（Pretty Good Privacy）中，每个用户签署其他用户的公钥，形成信任链。

4. 结合区块链等去中心化技术：

   • 将公钥信息记录在区块链中，利用区块链的不可篡改性确保公钥的真实性。

DNSSEC的新标记与状态解析

DNSSEC（DNS Security Extensions）引入了一些新的标记和状态，用于处理DNS查询中的安全性验证。这些标记和状态通过查询（Query）和应答（Response）中的特定字段传递信息，帮助解析器和递归服务器更有效地验证DNS数据的真实性和完整性。

---

标记说明

1. Checking Disabled (CD)

   • 用途：由解析器（Resolver）在查询中设置，表示递归服务器不需要进行真实性验证，而是将未经验证的数据直接返回给解析器，由解析器自己进行验证。

   • 作用：

     • 设置CD标记：递归服务器不执行DNSSEC验证。

• 未设置CD标记：递归服务器负责验证DNS数据的真实性。

---

1. Authenticated Data (AD)

   • 用途：由递归服务器在应答中设置，表示应答中的Answer和Authority部分的所有数据都已通过DNSSEC验证。

   • 作用：

     • 设置AD标记：表示数据已通过验证，且可信。

• 未设置AD标记：表示数据尚未验证或验证失败。

---

1. DNSSEC OK (DO)

   • 用途：由递归服务器在查询中设置，表示递归服务器支持DNSSEC功能。

   • 作用：

     • 设置DO标记：权威服务器会在应答中提供DNSSEC相关信息（如签名、DS记录等）。

• 未设置DO标记：权威服务器不会返回任何DNSSEC信息。

---

递归服务器的4种验证状态

递归服务器在处理DNSSEC验证时，根据应答的安全性和签名信息，将其分为以下四种状态：

1. Secure（安全）

• 定义：递归服务器具有一个可信的信任锚（Trust Anchor），并能通过信任链验证应答中的所有签名。

• 特点：

  • 应答中的Answer和Authority部分的数据已被验证。
  • AD标记：递归服务器在应答中设置AD标记。

• 示例场景：

  • 权威服务器提供了签名记录，递归服务器验证成功，并返回可信数据。

---

2. Insecure（不安全）

• 定义：递归服务器具有信任锚，并能沿着信任链验证到某个授权点（Delegation Point），但授权点之后的子域没有DNSSEC保护（没有DS记录）。

• 特点：

  • 应答数据被认为是未经保护的，但不一定是恶意的。
  • 无特定应答信息：应答中不设置任何DNSSEC相关标记。

• 示例场景：

  • 某子域未启用DNSSEC签名，但父域使用了DNSSEC。

---

3. Bogus（虚假）

• 定义：递归服务器具有信任锚，并且根据授权信息数据应该被签名，但实际应答未通过验证。可能原因包括：

  • 签名缺失。
  • 签名过期。
  • 使用了不受支持的签名算法。
  • 相关NSEC记录缺失等。

• 特点：

  • 应答被认为是无效的。
  • RCODE=2：返回码为"Server Failure"，表示应答失败。

• 示例场景：

  • 权威服务器返回了一个伪造签名或签名超时。

---

4. Indeterminate（不确定）

• 定义：递归服务器缺少信任锚，无法判断应答的安全性，默认进入“不确定”状态。

• 特点：

  • 无法确认数据的安全性或真实性。
  • 无特定应答信息：没有标记或特殊状态返回。

• 示例场景：

  • 权威服务器未提供任何签名，递归服务器也没有信任锚。

---

信任链的验证过程

DNSSEC通过信任链的方式逐级验证DNS数据的安全性：

1. 客户端发送查询，可能包含CD或DO标记。
2. 递归服务器根据信任锚和DNSSEC记录验证每一级域名（如根、顶级域com、二级域example.com）。
3. 根据验证结果，递归服务器确定应答的状态（Secure、Insecure、Bogus、Indeterminate），并设置适当的标记（如AD标记）。

---

总结

• 标记功能：
  • CD：解析器控制验证。
  • AD：数据已验证。
  • DO：支持DNSSEC查询。
• 递归服务器状态：
  • Secure：完全可信的数据。
  • Insecure：数据无DNSSEC保护，但不一定恶意。
  • Bogus：数据验证失败，可能伪造。
  • Indeterminate：无法确定数据安全性。

这些机制确保了DNSSEC能够有效处理DNS查询中的安全性问题，同时为不同的验证场景提供灵活性和可扩展性。

DNSSEC域名解析过程示意图

1. 用户主机发起DNS查询请求，查询www.verisign.com的A记录。

2. Stub Resolver（客户端的DNS解析器）向递归服务器发起查询。

   • 如果设置了CD标记（Checking Disabled），则递归服务器不进行DNSSEC验证，由Stub Resolver自己检查。
   • 如果没有设置CD标记，递归服务器会根据DNSSEC规则进行数据验证。

3. 递归服务器首先向根域服务器发起查询请求，获取根域的NS记录，并获取根域的DNSKEY（根密钥）。

   • 根服务器返回：
     • NS记录（表示根域有权向下委派）；
     • DS记录（用于验证子域的DNSSEC密钥）；
     • RRSIG（签名记录，用于验证DNS数据的完整性）；
     • DO标记：表示根服务器支持DNSSEC，并返回DNSSEC相关信息。

4. 递归服务器向.com域名的权威服务器查询，获取.com域的NS记录及com的DS记录（指向子域verisign.com的签名密钥）。

   .com域名的权威服务器返回：

   • DS记录：指向verisign.com的DNSSEC密钥。
   • RRSIG：签名记录，用于验证com区的DNS数据。
   • DO标记：表示该查询支持DNSSEC。
   • DS记录（com区的DS记录）。

5. 递归服务器继续向verisign.com域的权威服务器查询，获取verisign.com的NS记录及verisign.com的DS记录，并进行验证。

   verisign.com域的权威服务器返回：

   • DS记录：指向www.verisign.com的签名密钥。
   • RRSIG：签名记录，用于验证verisign.com区的DNS数据。
   • DO标记：表示该查询支持DNSSEC。

6. 递归服务器继续向www.verisign.com查询，最终获得www.verisign.com的A记录。

   www.verisign.com的权威服务器返回：

   • A记录：返回www.verisign.com的IP地址。
   • RRSIG：签名记录，用于验证A记录的真实性。
   • DO标记：表示支持DNSSEC。

7. 递归服务器验证整个过程中的DNSSEC签名：

   • 验证根域的RRSIG签名，确保根域的数据可信。
   • 验证com区的DS和RRSIG，确保com的DNS数据可信。
   • 验证verisign.com的DS和RRSIG，确保verisign.com的DNS数据可信。
   • 最后，验证www.verisign.com的A记录和签名，确保返回的A记录可信。

8. 验证成功后，递归服务器将www.verisign.com的A记录返回给Stub Resolver，并在响应中设置AD标记（Authenticated Data），表示数据已通过DNSSEC验证。

---

DNSSEC标记和记录

• DO (DNSSEC OK) 标记：由递归服务器在查询中设置，表示该递归服务器支持DNSSEC。递归服务器会在应答中处理DNSSEC相关的信息（如签名、DS记录等）。
• CD (Checking Disabled) 标记：由Stub Resolver在查询中设置，表示递归服务器无需验证DNSSEC，验证工作由Stub Resolver自己负责。
• AD (Authenticated Data) 标记：由递归服务器在响应中设置，表示应答中的数据已经通过DNSSEC验证。
• DS (Delegation Signer) 记录：指向子域的KSK（Key Signing Key）的哈希值，用于父zone信任子zone的密钥。
• RRSIG 记录：签名记录，用于验证DNS数据的真实性。
• root key、.com key、verisign.com key：这些密钥用于签署各个区的DNS数据，以确保DNSSEC验证过程的可信性。

---

总结

1. 解析流程：递归服务器从根服务器开始，通过信任链逐级验证DNSSEC签名，直到获得最终的A记录。
2. CD标记：禁用递归服务器的DNSSEC验证，由客户端进行验证。
3. DO标记：表示递归服务器支持DNSSEC。
4. AD标记：表示应答数据已经通过验证。
5. DNSSEC的作用：通过DS记录和RRSIG签名，确保每个DNS查询的安全性，避免中间人攻击和数据篡改。

在带有DNSSEC的验证通信中，递归服务器会逐步验证每个DNS数据的真实性，以确保数据的完整性和来源的可信性。以下是DNSSEC验证过程的示意图描述，展示了从用户主机到根域、再到子域的逐层验证过程。

DNSSEC 要点梳理

DNSSEC（Domain Name System Security Extensions）通过数字签名机制，确保 DNS 数据的完整性和真实性，解决传统 DNS 存在的安全问题（如缓存投毒和伪造数据）。以下是 DNSSEC 的核心要点和机制：

---

1. 签名的对象

• RRset：

  • DNSSEC 签名的对象不是单独的资源记录（RR），而是一个RRset。

  • RRset

    ：同名（NAME）同类型（TYPE）的全部资源记录集合。

    • 例如，对于域名 example.com 的 A 记录（IPv4 地址），其 RRset 包含所有的 A 记录。

---

2. 引入的新资源记录

DNSSEC 在传统 DNS 的基础上增加了一些新的资源记录（RR）：

1. DNSKEY：
   • 作用：存储 DNSSEC 使用的公钥。
   • 类型：
     • KSK（Key Signing Key）：
       • 负责签名 DNSKEY RRset（即对整个 DNS 区域的公钥进行签名）。
       • 较少更换，作为信任链的入口。
     • ZSK（Zone Signing Key）：
       • 负责签名所有其他 RRset（除 DNSKEY RRset 外）。
       • 更频繁更换，主要用于日常操作。
2. DS（Delegation Signer）：
   • 作用：存储父区域中子区域公钥的摘要（指纹）。
   • 用途：在父子区域之间建立信任链，用于验证子区域的 DNSKEY。
   • 生成方式：对子区域的 DNSKEY 使用哈希函数计算摘要，父区域中存储此 DS 记录。
3. RRSIG（Resource Record Signature）：
   • 作用：存储 RRset 的签名。
   • 用途：用于验证 RRset 的完整性和真实性。
   • 关联：每个 RRset 都有一个对应的 RRSIG，签名由对应的 ZSK 或 KSK 生成。
4. NSEC/NSEC3：
   • 作用：证明查询的域名或记录不存在。
   • NSEC：
     • 提供链式证明，列出当前域名后一个存在的域名，用以证明某域名不存在。
   • NSEC3：
     • 使用哈希化的域名，增强隐私保护，避免泄露所有域名信息。

---

3. 信任链

DNSSEC 通过公钥和签名建立自上而下的信任链：

• 信任链形式：

  DNSKEY -> [DS -> DNSKEY]* -> RRset

  • DNSKEY：签名的起点，通常从根区域的 KSK 开始。
  • DS：父区域提供的子区域 DNSKEY 的摘要。
  • RRset：最终返回的数据资源记录集合。
  • 括号中的 [DS -> DNSKEY] 可选且可重复，表示父子区域之间的多级验证。

• 信任链解析过程：

  1. 从根区的 KSK 开始，验证根区 DNSKEY 的签名。
  2. 使用根区 DNSKEY 验证根区中子区域（如 .com）的 DS。
  3. 逐级验证子区域的 DNSKEY，直至目标区域。
  4. 最后使用目标区域的 DNSKEY 验证最终的 RRset。

---

4. DNSSEC 解析与验证

4.1 DNSSEC 解析

• 客户端在 DNS 查询时设置 DO（DNSSEC OK）标志位，表示需要 DNSSEC 数据。
• 响应内容：除传统 DNS 记录外，还返回以下内容：
  • DS 记录：提供子区域 DNSKEY 的摘要。
  • RRSIG 记录：RRset 的签名。
  • NSEC/NSEC3 记录：证明域名或记录的不存在。

4.2 DNSSEC 验证

• 验证过程需要递归服务器或本地验证器支持 DNSSEC 验证功能。
• 验证内容：
  1. 对应 RRset 是否有 RRSIG 签名。
  2. 使用 DNSKEY 验证签名的正确性。
  3. 逐级验证信任链，确保从根区到目标区域的每一级签名都有效。
• 验证方式：
  • 自顶向下验证：从根区 KSK 开始，逐级验证到目标区域。
  • 自底向上验证：从目标区域开始，逐级验证到根区。

---

5. 实现问题

问题1：如何优化延迟？

• 延迟来源：
  1. 解析过程中，额外查询 DNSKEY、DS、RRSIG、NSEC 等记录，增加查询次数。
  2. 验证签名涉及多次哈希和公钥加密运算，计算开销较大。
• 优化方法：
  1. 缓存：
     • 缓存 DNSSEC 记录（如 DNSKEY 和 RRSIG），减少重复查询。
     • 缓存信任链的验证结果。
  2. 并行查询：
     • 对同一区域的多个记录（如 DNSKEY 和 RRSIG）同时查询。
  3. 批量验证：
     • 对批量查询结果进行一次性验证，而非逐条验证。

---

问题2：自顶向下 vs 自底向上验证

• 自顶向下验证：
  • 过程：
    1. 从根区 KSK 开始，逐级验证每一级的签名。
    2. 验证目标区域的签名及 RRset。
  • 优点：
    • 符合信任链的自然逻辑。
    • 更易确定每一级签名的来源合法性。
  • 缺点：
    • 每一级验证需要从根区开始，可能增加延迟。
• 自底向上验证：
  • 过程：
    1. 从目标区域开始，验证其 DNSKEY 和 RRSIG。
    2. 逐级向上验证父区域的 DS 和 DNSKEY，直至根区。
  • 优点：
    • 目标区域的验证更快，适合验证局部的结果。
  • 缺点：
    • 需要最终获得根区的可信信息，否则信任链无法完成。

---

总结

DNSSEC通过签名和信任链机制，增强了DNS解析的安全性，解决了传统DNS的安全问题，但也引入了延迟和实现复杂性。其核心要点包括：

1. 签名对象：RRset。
2. 新增记录：DNSKEY、DS、RRSIG、NSEC/NSEC3。
3. 信任链：从根区KSK开始，逐级验证到目标区域的RRset。
4. 解析与验证：通过DO标志位请求DNSSEC数据，自顶向下或自底向上完成验证。

针对延迟和验证方向的问题，优化缓存与并行查询可提升性能，而具体验证方向需根据实际场景选择适合的策略。

DNSSEC不保护整个DNS系统

DNSSEC（DNS Security Extensions）通过为DNS数据提供签名和验证机制，确保DNS查询结果的真实性和完整性。然而，DNSSEC并不保护整个DNS系统，特别是通信过程和绕过验证的攻击，这些都可能成为潜在的攻击目标。

DNSSEC保护的范围

DNSSEC的核心目标是通过为DNS数据（如A记录、MX记录等）添加签名来确保数据的完整性和真实性。它通过引入数字签名和公钥基础设施（PKI）来验证每个DNS响应的签名，确保返回的数据没有被篡改。

• DNSSEC保护的部分：
  • DNS数据本身：DNSSEC确保返回的DNS记录在传输过程中没有被篡改。通过签名机制，每个DNS数据项都带有相应的签名，递归服务器可以根据父域和子域的信任链来验证数据的完整性。
  • 信任链：DNSSEC通过从根域开始，逐级验证父域到子域的信任链（例如，根域 → .com → example.com）来确认数据的真实性。

然而，DNSSEC并不直接保护DNS系统的通信过程，也不防止所有可能的攻击，比如绕过DNSSEC验证。

DNSSEC不保护的部分

1. 通信过程的保护（不保护传输通道）

• 非设计目标：DNSSEC的设计目的是保护DNS数据的真实性和完整性，而不是保护数据传输过程本身。这意味着DNSSEC并不加密DNS通信，因此在数据传输过程中，攻击者仍然可以通过中间人攻击（MITM）*来监听或修改DNS查询和响应。它无法防止网络层面上的攻击，如*DNS劫持、DNS放大攻击等。
• 数据保护与通信保护的区别：DNSSEC只关心DNS数据是否在传输中被篡改或伪造，而不关心数据的传输是否受到保护。因此，攻击者可以通过控制网络传输路径来干扰通信，但DNSSEC本身无法检测到或防止这种情况。

2. 伪造应答内容

• 攻击者可能伪造DNS响应内容，绕过DNSSEC验证。例如，攻击者可以伪造DNS响应，并将其发送到递归服务器或客户端，试图欺骗系统返回伪造的域名解析结果。
• 如果攻击者能够控制或接管递归服务器的查询过程（如通过DNS缓存投毒或DNS劫持），即使DNSSEC能够验证DNS数据的真实性，但仍然可能受到恶意响应的影响，尤其是假冒的DNSSEC签名。

3. 伪造DNSSEC验证结果

• 攻击者可以伪造DNSSEC验证结果，例如通过欺骗中间的递归服务器或客户端，让它们错误地认为DNS响应是经过有效签名的，而实际上数据已经被篡改或伪造。这种类型的攻击需要攻击者能够控制DNS解析过程。

DNSSEC的设计疏忽

• 保护通信过程 vs. 保护数据本身：DNSSEC的目标明确是保护数据的完整性和真实性，而不是加密或保护数据传输过程。它的设计并没有考虑到在传输过程中可能发生的攻击。
• 非设计目标：DNSSEC没有考虑保护DNS通信的安全性。它并不提供加密，也没有提供类似HTTPS中SSL/TLS协议那样的安全传输通道。因此，DNSSEC主要关注数据本身的安全，而忽略了如何保护数据传输过程。

无需保护：用户可自行验证数据

• DNSSEC的开放性：DNSSEC的设计并没有要求用户依赖递归服务器进行DNSSEC验证，用户可以自行验证应答内容的真实性和完整性。只要用户知道根区的KSK（Key Signing Key），就可以通过递归服务器或本地工具验证DNS响应的签名。

  例如：

  • 用户可以使用工具（如dig）直接查询域名的DNSKEY记录，获取DNSSEC签名，并验证应答的真实性。
  • 递归服务器在验证DNSSEC时，会根据根区的信任链和DNSSEC密钥对响应进行验证，确保数据是安全的。

总结

1. DNSSEC保护的是DNS数据的完整性和真实性，通过为DNS响应添加数字签名来防止篡改和伪造。
2. DNSSEC不保护通信过程，它不加密数据，也不防止网络层的攻击（如DNS劫持、MITM攻击等）。
3. 攻击者可以绕过DNSSEC验证，伪造DNS响应，或者通过恶意篡改DNSSEC验证结果进行欺骗。
4. DNSSEC设计的目标是保护数据本身的安全，而不是保护整个通信过程。
5. 用户可以自行验证DNSSEC数据的真实性，只需要获取根区的KSK即可进行验证。

因此，尽管DNSSEC是DNS安全的一个重要步骤，但它并不是万无一失的，仍然需要与其他安全措施（如TLS/SSL、加密DNS传输等）结合使用，来确保整个DNS系统的安全性。

加密DNS + DNSSEC = 更全面的安全

将加密DNS与DNSSEC结合，可以在DNS解析中同时保护通信过程和数据完整性，提升整体安全性。以下是两者的特点及结合后带来的安全优势：

---

加密DNS的特点

1. 保护通信过程：
   • 加密DNS（如DNS-over-HTTPS（DoH）或DNS-over-TLS（DoT））通过加密DNS查询和响应的数据流，防止通信过程中被窃听或篡改。
   • 它提供隐私保护，使第三方无法轻易查看用户访问的域名。
2. 不足之处：
   • 加密DNS只加密了通信内容，但并不验证递归服务器返回的DNS数据的真实性。
   • 如果递归服务器本身受到攻击（如DNS缓存投毒），则即使通信加密，用户仍可能收到伪造的DNS数据。

---

DNSSEC的特点

1. 保证应答内容可信：
   • DNSSEC通过为DNS数据添加数字签名，确保返回的DNS记录在传输过程中未被篡改。
   • 它提供数据完整性和真实性验证，但不加密通信过程。
2. 不足之处：
   • DNSSEC无法防止通信内容被窃听或阻止中间人攻击（MITM）。
   • 不保护用户的隐私（例如，明文的DNS请求可以被监听）。

---

加密DNS + DNSSEC 的结合

将加密DNS和DNSSEC结合，能在两方面提供全面的安全保护：

1. 通信安全：加密DNS保护DNS查询和响应的数据流，防止窃听和篡改。
2. 数据完整性与真实性：DNSSEC验证返回的DNS数据是否可信，防止伪造和篡改。

通过这种组合：

• 加密DNS确保通信过程安全。
• DNSSEC确保数据本身可信。
• 两者结合后，用户主机（Stub Resolver）可以信赖递归服务器提供的应答内容，且保证隐私不被泄露。

---

公式解释：加密DNS + DNSSEC = 安全 ≡ 递归服务器可信

1. 加密DNS提供了通信过程的保护，防止数据被窃听或中途篡改。

2. DNSSEC验证了递归服务器返回的数据的真实性和完整性。

3. 两者结合后，用户可以：

   • 确保与递归服务器之间的通信是加密的。
   • 验证递归服务器返回的DNS应答是否经过有效签名，确保数据可信。

4. 递归服务器可信

   意味着：

   • 用户可以信赖递归服务器的返回结果，既不会被中间人攻击，也不会接收到伪造的数据。

---

安全提升后的工作流程

结合后DNS解析的步骤：

1. 加密通信过程：
   • 用户主机通过DoH或DoT向递归服务器发送加密的DNS查询。
   • 递归服务器返回加密的DNS应答，保护隐私。
2. 验证DNSSEC签名：
   • 用户主机或递归服务器使用DNSSEC验证DNS数据的签名。
   • 通过信任链（如根域的KSK、公钥验证）确保DNS应答的真实性和完整性。
3. 用户主机的保障：
   • 数据从递归服务器到用户主机的传输是安全的（加密DNS）。
   • 数据本身没有被篡改或伪造（DNSSEC）。

---

局限性和未来改进

1. 递归服务器信任问题：
   • 即使结合加密DNS和DNSSEC，用户仍需要信任递归服务器不会返回恶意数据或被攻击。
   • 引入更多独立验证机制（如本地DNSSEC验证）可以进一步提升安全性。
2. 隐私与性能：
   • 加密DNS和DNSSEC可能增加网络延迟（尤其是验证信任链）。
   • 未来技术（如QNAME最小化、改进协议效率）可以在保护隐私的同时提升性能。

---

总结

加密DNS + DNSSEC的结合提供了全面的DNS安全：

• 通信过程安全：通过加密DNS，保护用户隐私，防止中间人攻击。
• 数据完整性与真实性：通过DNSSEC，确保DNS数据未被篡改或伪造。
• 最终结果：递归服务器既可信又安全，为用户提供可靠的域名解析服务。

加密DNS for everything 的优劣分析

加密DNS（如DoH、DoT）提供了通信过程的加密和隐私保护，但在“完全依赖加密DNS（加密DNS for everything）”的场景下，存在一些明显的优点和缺点，同时暴露出DNSSEC不可替代的重要性。

---

优点：完整保护DNS通信过程

1. 隐私保护：
   • 加密DNS通过加密传输保护用户的DNS查询内容，防止第三方（如ISP或中间人）监听用户的访问记录。
   • 适用于需要高度隐私的环境，例如防止流量分析或追踪。
2. 防止中间人攻击（MITM）：
   • 加密DNS通过安全的传输层协议（如TLS）确保DNS数据的传输安全，阻止恶意拦截和篡改。
3. 适应现代网络需求：
   • 加密DNS适合嵌入到现代浏览器或操作系统中（如Mozilla的DoH实现），支持用户设备直接与递归服务器安全通信。

---

缺点与风险：

1. 增加DoS风险：
   • 加密DNS需要更多的计算资源处理TLS握手和加密传输，可能显著增加权威服务器的开销。
   • 在大规模DNS查询场景下，加密DNS可能导致权威服务器成为DoS攻击的目标。
2. 递归服务器控制范围，但权威服务器无法限制：
   • 递归服务器可以选择是否为特定用户提供服务，从而实现某种程度的流量管理。
   • 权威服务器由于需要响应全球范围的查询，无法对请求来源进行控制，可能因滥用或攻击而承受较大压力。
3. 信任转移到外部系统（PKI的依赖）：
   • 加密DNS依赖外部PKI（公钥基础设施）来认证服务器身份。例如，通过CA（证书颁发机构）为递归服务器或权威服务器签发证书。
   • 如果PKI系统被破坏或信任受到质疑（如CA被攻破），加密DNS的信任模型将崩溃。
4. 通信加密不等于数据可信：
   • 加密DNS只保证数据在传输中的安全，并不验证数据本身是否被伪造或篡改。
   • 如果递归服务器返回的结果被恶意操控（例如缓存投毒），用户依然可能被误导。

---

DNSSEC的不可替代作用

1. 确保数据完整性和真实性：
   • DNSSEC通过签名验证机制，确保从权威服务器返回的DNS数据未被篡改。
   • 即使传输过程中存在恶意行为，DNSSEC也能通过信任链验证数据是否可信。
2. 补充加密DNS的不足：
   • 加密DNS保护通信过程，但不验证数据内容。
   • DNSSEC验证数据内容，但不保护通信过程。两者结合可以同时解决传输和数据的安全问题。
3. 无需依赖外部PKI：
   • DNSSEC的信任链由DNS自身的结构提供（从根区的KSK到各子域的ZSK），不依赖传统的PKI体系，减少外部依赖带来的风险。

---

是否“加密DNS for everything”？

完全依赖加密DNS并非最佳选择，以下原因导致其需要与DNSSEC结合使用：

1. 单一机制的局限性：
   • 加密DNS只能保护通信，不保护数据内容。
   • 在某些场景下（如缓存投毒攻击、递归服务器被控制），加密DNS不足以保证最终的安全性。
2. 性能和扩展性问题：
   • 加密DNS的大规模部署增加了权威服务器的开销，可能导致性能下降，尤其是在DoS攻击或高负载场景下。
   • DNSSEC的签名验证相比加密DNS具有更好的扩展性，因为其验证过程依赖本地缓存和信任链，而不需要实时的加密通信。
3. 最佳实践：
   • 加密DNS应与DNSSEC结合，形成“通信安全 + 数据真实性”的综合解决方案。
   • 用户设备（桩解析器）可以通过加密DNS与递归服务器通信，同时验证DNSSEC签名，确保通信过程和数据本身都可信。

---

总结

• 加密DNS for everything 的优点：
  • 提供全面的通信过程加密。
  • 保护用户隐私，防止中间人攻击。
• 加密DNS的局限性：
  • 无法验证数据真实性。
  • 增加权威服务器的负担。
  • 信任依赖外部PKI，存在单点失效风险。
• DNSSEC的作用：
  • 确保DNS数据的完整性和真实性。
  • 不依赖外部PKI，独立于通信过程。

最终结论： “加密DNS for everything”并不足以解决所有DNS安全问题。只有结合DNSSEC，才能真正实现通信过程和数据内容的全面保护。

ODNS的隐私保护效果

ODNS（Oblivious DNS，或称“隐私保护DNS”）是一种设计用于提高DNS查询隐私的协议。它通过某些加密和隐私保护机制，避免了传统DNS查询中潜在的隐私泄露风险。ODNS的目标是确保在DNS解析过程中，不同的参与方仅知道必要的信息，而不会暴露用户的访问行为或查询内容。

---

ODNS的隐私保护效果：

1. 避免“人”同时知道“who”和“what”：

   • “who”：指的是发起DNS查询的用户（即查询的来源）。
   • “what”：指的是用户实际查询的域名或资源（即查询的目标）。

   在传统的DNS查询中，递归服务器既能知道查询的来源（即“who”），也能知道查询的内容（即“what”）。例如，递归服务器能看到用户访问的域名（如 www.example.com）及其对应的IP地址。

   而ODNS的设计目标是通过某些机制让“who”和“what”彼此分离，即让任何单一的参与方无法同时获取这两个信息，从而保护用户的隐私。

---

ODNS隐私保护的实现机制：

1. ODNS桩解析器在本地：
   • ODNS桩解析器（Stub Resolver）：通常位于用户的设备上，负责发起DNS查询请求，但它并不直接与权威DNS服务器通信。相反，它会将查询请求发送给一个隐私保护的递归DNS服务器。
   • 通过ODNS，用户设备仅仅知道查询的目标域名（“what”），但在查询过程中，用户的设备通过加密机制与递归服务器交互，而不会直接暴露给递归服务器。
2. 递归服务器知道“who”，不知道“what”：
   • 在ODNS系统中，递归DNS服务器负责处理和转发DNS查询，但它不能直接看到查询的域名。
   • 递归服务器会通过加密机制接收到加密的DNS查询请求，并将其转发给权威DNS服务器。
   • 递归服务器知道查询来源（即“who”），因为它接收了来自用户设备的查询请求，但无法解密查询内容，因此不知道查询的域名（即“what”）。
3. ODNS权威服务器知道“what”，但不知道“who”：
   • ODNS权威DNS服务器负责最终提供DNS解析结果（如IP地址），但它只能看到被加密的查询内容（即“what”），并且无法知道查询请求的来源（即“who”）。
   • 权威服务器接收到的查询请求是加密的，因此即使它能解析域名和资源信息，它也无法得知发起查询的用户是谁。

---

隐私保护效果总结：

• 用户隐私得到保护：在ODNS协议中，递归服务器和权威服务器不会同时知道用户的身份和查询的内容。递归服务器仅能看到查询请求的来源，但无法了解查询的内容；权威服务器仅能解析出查询内容，但无法知道是哪个用户发起的查询。
• 去中心化的隐私控制：通过将查询内容加密，ODNS实现了“去中心化的隐私保护”。即使存在中间的递归DNS服务器或权威DNS服务器，它们也无法共同推断出完整的查询信息，从而有效保护了用户的隐私。
• 提升对抗网络监控的能力：由于ODNS使得查询来源和内容完全隔离，它能有效避免传统DNS系统中可能存在的隐私泄漏（例如，ISP监控用户的DNS查询行为）。只有用户的设备和ODNS的桩解析器之间有直接的联系，因此能显著减少DNS查询泄漏给外部实体的风险。

---

总结

ODNS（Oblivious DNS）通过加密和分离查询内容与来源的机制，有效保护了用户的隐私。具体来说：

• ODNS桩解析器保证了查询的隐私，不会直接暴露给递归服务器。
• 递归服务器仅能看到请求的来源（“who”），但无法解析具体查询的内容（“what”）。
• ODNS权威服务器知道查询的内容（“what”），但无法知道发起查询的用户是谁（“who”）。

这种设计使得ODNS在保护用户隐私方面具有显著优势，尤其是在防止网络监控和数据泄露的背景下。