--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "zh-Hans" category: "DNS与技术基础" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/zh/cihui/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" es: "https://tldlog.com/es/glosario/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" it: "https://tldlog.com/it/glossario/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" --- # DNSSEC 域名系统安全扩展 DNS的扩展，为DNS应答添加数字签名。借助这些签名，解析器（为用户查询名称的服务器）可以核实应答是否真实、在传输途中是否被更改。所有者通过其DNS托管商和注册服务机构启用它。 DNSSEC为域名系统的应答加上数字签名，使计算机能够核实应答确实来自域名的所有者，且在传输途中未被篡改。它不隐藏任何内容，也不能阻止所有攻击。启用它需要DNS服务商、注册服务机构和注册管理机构共同配合。 ## 用浅显的话说，DNSSEC能防范什么 有人访问example.com时，解析器会查询它的地址。没有DNSSEC时，攻击者只要向解析器提供伪造的应答，就能把访问者引向错误的服务器。有了DNSSEC，进行验证的解析器会检查签名，并拒绝伪造的应答。 RFC 4033（2005年3月）规定了DNSSEC提供的保障：DNS数据的来源证明和完整性。它不提供保密性，因此应答仍然可读，也不能防范拒绝服务攻击。它只涵盖DNS应答，不涉及网络钓鱼或注册服务机构账户被盗用。RFC 9364（2023年2月）将DNSSEC称为验证DNS数据的现行最佳实践；某个域名是否使用它，由其所有者决定。 ## 从根到域名的信任链如何运作 进行验证的解析器从一个它已经信任的密钥出发：信任锚，即由IANA发布的根区密钥签名密钥。它从这里沿着一条链条进行： 1. 根区保存着.com的一条已签名的DS记录。 2. 这条DS记录与.com区域中的一个密钥相匹配，解析器借此验证.com的记录，其中包括example.com的DS记录。 3. 这条DS记录与example.com的密钥相匹配，由此验证该域名自身的记录。 如果某个已签名区域的上级区域中没有DS记录，它就是一个“island of security”（安全孤岛）：无法从根开始对其进行验证。 如果每个签名都验证通过，应答即为安全（secure）；如果有签名证据表明上级区域中没有该区域的DS记录，应答即为不安全（insecure）；如果预期的签名缺失、过期或无法使用，应答即为伪造（bogus）（RFC 4033）。对于伪造应答，解析器通常返回错误SERVFAIL（RFC 4035）。 ## 密钥和记录：KSK、ZSK、DNSKEY、DS和RRSIG - **DNSKEY**记录发布区域的公钥。 - **RRSIG**记录存放签名，每个签名只在开始日期和到期日期之间有效。 - **DS**记录位于上级区域，存放密钥标签、算法编号以及下级区域密钥的摘要。 - **KSK**（密钥签名密钥）只对区域的密钥集进行签名，上级区域的DS记录指向它。**ZSK**（区域签名密钥）对其他所有内容进行签名。 RFC 6781（2012年12月）指出，验证方对这两种密钥一视同仁：这种划分是出于运维考虑，有些区域用同一个密钥承担两种角色。 证明某个名称不存在需要专门的记录。NSEC记录给出下一个存在的名称，这使任何人都能列出整个区域（即“zone walking”，区域遍历）。NSEC3（RFC 5155）先对名称进行哈希处理，但仍会暴露区域规模等细节。 ## 启用DNSSEC：注册服务机构、注册管理机构和DNS服务商各自的工作 1. DNS服务商对区域进行签名，并发布DNSKEY和RRSIG记录。 2. DS数据或密钥数据被提交给注册服务机构。 3. 注册服务机构通过带secDNS扩展的EPP（RFC 5910，2010年5月）将其发送给注册管理机构，形式可以是DS数据，也可以是密钥数据，由注册管理机构据此生成DS记录。 4. 注册管理机构在顶级域区域中发布DS记录。 如果注册服务机构同时也是DNS服务商，第1步到第3步往往只是一项设置。 对于通用顶级域，2013年《注册服务机构认证协议》要求注册服务机构使用RFC 5910，将添加、删除或更改密钥材料的请求转交给支持DNSSEC的注册管理机构。基本注册管理机构协议（2024年1月21日批准，截至2026年10月仍为现行版本）要求通用顶级域注册管理机构对其区域进行签名，并接受下级域名提交的密钥材料。国家和地区代码顶级域的规则各不相同，需向注册服务机构或注册管理机构核实。 此外还有一条自动化途径：DNS服务商发布CDS和CDNSKEY记录，说明DS记录应当是什么，部分注册管理机构和注册服务机构会扫描这些记录。RFC 8078（2017年3月）增加了一种用于移除DNSSEC的信号；RFC 9615（2024年7月）使上级区域能够在启用DNSSEC之前，以密码学方式验证这些记录。 ## 可能出现的问题：签名过期、密钥轮换和更换DNS服务商 - **签名过期**。RRSIG记录未及时更新，会使应答成为伪造应答。 - **DS记录没有匹配的密钥**。RFC 6781称之为“security lameness”：该域名对所有进行验证的解析器都会失效，修复也需要时间才能扩散。因此更换KSK时，必须先让新的DS记录出现在上级区域，再移除旧密钥。 - **更换DNS服务商**。旧运营方掌控着密钥。最佳方法是协调进行密钥轮换。如果旧运营方不配合，就先移除DS记录，再更换域名服务器，待变更扩散后再添加新的DS记录。其间该域名处于未签名状态，RFC 8078认为这比验证失败更可取。较短的TTL有助于缩短这一过程。 对于使用验证型解析器的用户，故障表现为SERVFAIL，而该域名对其他所有人可能仍然正常。 在根区层面，截至2026年10月9日，ICANN计划于2026年10月11日更换根区KSK：由KSK-2024（密钥标签38696）接替KSK-2017（密钥标签20326），后者将于2027年1月11日撤销，并于2027年3月22日移除。这涉及的是验证型解析器的运营方，他们需要新的信任锚，与注册人无关。 ## DNSSEC与加密DNS的区别 DNSSEC对数据进行签名，使任何解析器都能核验，但所有内容仍然可读。基于TLS的DNS（DoT）和基于HTTPS的DNS（DoH）对用户设备与解析器之间的连接进行加密，从而保护隐私，但它们不能证明数据来自区域所有者。两者相辅相成。 ## 来源 - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## 相关术语 - [DS记录](https://tldlog.com/zh/cihui/ds-jilu/) - [DNSKEY记录](https://tldlog.com/zh/cihui/dnskey-jilu/) - [解析器](https://tldlog.com/zh/cihui/jiexiqi/) - [DNS](https://tldlog.com/zh/cihui/dns/)