域名系统 DNS 是互联网的电话簿，每天将人类可读的名称翻译成 IP 地址数十亿次。DNS 数据库存储着关键的 DNS 记录，如 IP 地址和域名别名，因此成为网络威胁的目标。但这一关键基础设施是上世纪 80 年代设计的，没有内置安全性。传统的 DNS 验证依赖于为响应匹配相同的 IP 地址，这是不安全的，因为 IP 地址可以被欺骗。DNSSEC 的出现弥补了这一根本缺陷，为原本纯粹依靠信任运行的系统增加了加密验证功能。
DNSSEC 概述
域名系统安全扩展（通常称为DNSSEC）是DNS Security Extensions的缩写，是一套 IETF 协议规范，用于为 DNS 数据添加加密签名。这些签名允许 DNS 解析器验证它们接收到的信息是否真正来自权威来源，并且在途中未被篡改。
DNSSEC 解决的核心问题很简单：如果没有 DNSSEC，攻击者就可以向解析器缓存注入虚假的 DNS 响应。这种攻击被称为DNS 缓存中毒，可在用户不知情的情况下将其重定向到恶意网站。DNSSEC 通过数字签名启用数据来源验证并确保 DNS 记录的完整性，使用公钥加密技术并要求仔细管理 DNS 区域密钥以防止假冒和数据篡改，从而防止了这种情况的发生。
2000 年代初，互联网工程任务组（IETF）通过一系列 RFC（包括 RFC 4033、4034 和 4035）对 DNSSEC 进行了标准化。2010 年 7 月，ICANN 签署了 DNS 根区，建立了全球信任锚，使 DNSSEC 在全球的实际部署成为可能，这是 DNSSEC 部署的重要里程碑。
了解 DNSSEC 做什么和不做什么至关重要。DNSSEC 对 DNS 数据进行验证，确认A、AAAA、MX 和 TXT 记录是未经修改的真实记录。但是，它不会加密 DNS 查询或响应。任何人都可以看到 DNS 流量。要进行加密，您需要TLS DNS或HTTPS DNS 等辅助协议。
DNSSEC 也不能阻止对 DNS 基础设施的所有攻击。无论是否签署，大规模的 DDoS 攻击仍会使 DNS 服务器不堪重负。DNSSEC 无法阻止用户访问合法注册的钓鱼域名，而这些域名恰好看起来很有说服力。
由于需要进行密钥管理和建立信任链，实施 DNSSEC 可能比较复杂。 要成功部署 DNSSEC，父区域和链中的所有区域也必须签名。
目前，大多数顶级域都支持 DNSSEC –根据 ICANN 的数据，超过 1,400 个顶级域已签署 DNSSEC。然而，二级域名的采用情况却截然不同。只有约 1-2% 的 .com 区域启用了 DNSSEC，而 .nl （荷兰）和 .se（瑞典）等国家代码 TLD 则因强制政策而超过 90% 的签署率。
为什么要关注？因为如果没有 DNSSEC，贵组织进行的每一次 DNS 查询都很容易受到无声操纵。 攻击者如果在解析器的缓存中下毒，就可能将员工重定向到凭据收集网站或拦截电子邮件发送，而不会触发任何明显的警告。
DNS 和 DNSSEC 如何结合在一起
在深入了解DNSSEC 之前，让我们简要回顾一下当今域名系统的工作原理。当您在浏览器中输入 URL 时，计算机的存根解析器会与递归 DNS 解析器联系–通常由互联网服务提供商、企业网络或公共服务（如Google 的 8.8.8.8或Cloudflare 的 1.1.1.1）提供。DNS 解析器通过跟踪服务器链处理 DNS 查询，以检索正确的 IP 地址，从而确保高效、准确的解析。
考虑解析www.example.com。递归 DNS 解析器首先查询13 个逻辑根 DNS 名称服务器之一，询问有关.com 的信息。根服务器的回应是转到由威瑞信运营的.com TLD服务器。然后，解析器向 .com 服务器询问有关 example.com 的信息，并收到指向example.com 的权威名称服务器的另一个转介。最后，解析器查询该权威服务器，获得包含 www.example.comIP 地址的实际A 记录。
在这个分级系统中，各种 DNS 组件（如资源记录、权威名称服务器和区域签名密钥）共同管理、控制和保护每个 DNS 区域。
早在 1987 年，RFC 1034 和 1035 就定义了这一优雅的分级系统。问题出在哪里？经典的 DNS 协议在设计之初没有经过严格的身份验证。 主要通过匹配源 IP 地址和16 位交易 ID来验证响应—攻击者学会了利用这一系统。
2008 年的 Kaminsky 漏洞证明了这种设计的脆弱性。安全研究员丹-卡明斯基（Dan Kaminsky）指出，攻击者可以通过在单个查询窗口内大量猜测，高概率地向解析器缓存注入虚假响应。这一漏洞的披露引发了整个行业的紧急修补，并大大加快了DNSSEC 在全球范围内的部署。
DNSSEC 作为一个扩展层集成在现有 DNS 中，不会改变核心查询/响应模型。 对于未验证的解析器，未签名区仍可正常工作。验证解析器只需对已签名区执行额外的加密检查。 这种向后兼容性对整个 DNS 命名空间的逐步采用至关重要。
DNSSEC 核心概念和记录类型
DNSSEC 引入了几种新的 DNS 资源记录类型，它们共同创建了一个可验证的信任链。 了解这些记录和它们之间的关系，对任何处理签名区的人来说都是至关重要的。
DNSSEC 的基础单元是资源记录集（或 RRSet）。 这是一组具有相同名称、类型和类别的 DNS 记录。DNSSEC 不签署单个记录，而是签署整个 RRSets。 这种方法确保了原子完整性–如果不取消所有记录的签名，就无法篡改记录集中的一条记录。
RRSIG 记录包含覆盖 RRSet 的数字签名。 每个资源记录签名都使用区的私钥创建，包括签名者姓名、有效期和所用算法等元数据。解析器通过重新计算 RRSet 数据的哈希值并与加密签名进行核对，来验证这些签名。
DNSKEY 记录发布用于验证签名的公开密钥。 这些记录出现在区顶点（如 example.com。），并包含指示键作用的标志。 标志值 256 表示区签名密钥，257 表示密钥签名密钥。
DS 记录或授权签名者记录在父区域和子区域之间建立联系。它存储在父区域中，包含子区域公钥的加密哈希值。例如，example.com 的 DS 记录存储在 .com 区域，这样解析器就能验证 example.com 的 DNSKEY 记录是否真实。每个区的公钥都由其父区的私钥签名，这对建立 DNSSEC 信任链至关重要。这一过程可确保信任从父区域传递到子区域，形成一个安全、可验证的层次结构。
NSEC 和 NSEC3 记录支持经过验证的拒绝存在。 当 DNS 查询请求一个不存在的名称时，这些记录会证明该名称确实不存在–防止攻击者声称不存在的名称是真实的。NSEC 将现有名称按排序顺序串联起来，而 NSEC3 则使用加密散列记录名称，以防止轻易枚举区域内容。
CDS 和 CDNSKEY 记录支持自动密钥管理。 这些功能允许子区域向父区域发送更新的 DS 或 DNSKEY 信息，减少了传统上需要与注册商进行的人工协调。
区域签名密钥（ZSK）和密钥签名密钥（KSK）之间的分离值得特别注意。 ZSK 签署常规区域数据（A、AAAA、MX 记录），而 KSK 只签署 DNSKEY RRSet 本身。 这种分离使操作员可以频繁地旋转 ZSK，同时保持更稳定的 KSK 及其在父区的相关 DS 记录不变。
名称系统安全扩展
域名系统安全扩展（NSSE）是一套全面的协议和标准，旨在加强域名系统（DNS）的安全性。NSSE 的核心是DNSSEC，它使用数字签名和公钥加密来验证 DNS 数据并保证其完整性。这些系统安全扩展的主要目的是抵御 DNS 欺骗和 DNS 缓存中毒等威胁–这些攻击可以操纵 DNS 数据并将用户重定向到欺诈网站。
通过利用名称系统安全扩展，域名所有者可以确保与其域名相关的 DNS 数据在互联网上传输时是真实的，且未被篡改。这是通过使用公钥基础设施实现的，每个签名区都会发布一个公钥，解析器使用该公钥验证 DNS 记录上的数字签名。因此，用户和应用程序可以相信他们从域名系统接收到的信息是合法的，这有助于维护用户的信任，防范各种网络威胁。
DNSSEC 验证如何端到端工作
DNSSEC 验证遵循 DNS 解析路径，从称为信任锚的已知起点开始验证。对于大多数解析器来说，这个锚是根区的 KSK，通过 IANA 和解析器软件更新分发。当验证递归解析器处理已签名域的查询时，它会在 DNS 层次结构的每一步执行加密验证。解析器已经信任根 DNSKEY。使用该密钥，它将验证根区的 RRSIG 是否覆盖了 TLD 的 DS 记录（如 .com）。然后，它会获取 .com 的 DNSKEY 并验证其是否与 DS 哈希值匹配。这一过程一直持续到目标域。
考虑在完全签名环境中查询 www.example.com。解析器会进行验证：
- 根 DNSKEY（可信锚点）签署 .com 的 DS 记录
- .com 的 DNSKEY 与 DS 哈希值相匹配，并签署 example.com 的 DS 记录
- example.com 的 DNSKEY 与其 DS 匹配，并为 www 的 A 记录签名
这样，从根节点到所请求的 DNS 记录就形成了一个完整的信任链。 任何不匹配–无效签名、过期的 RRSIG 或 DS/DNSKEY 哈希失效–都会破坏链。
您可以使用 ICANN 故意配置错误的dnssec-failed.org 等测试域观察验证失败情况。验证解析器会返回该域名的 SERVFAIL，完全阻止访问。而对于未验证解析器的用户（全球仍有约 70%），域名解析正常–这说明了当前部署中存在的差距。
DNSSEC 不会改变 HTTP 或 SMTP 等应用协议。它只是确保应用程序收到的IP 地址和其他 DNS 数据是真实的、未经修改的。浏览器仍可正常进行 HTTPS 连接；DNSSEC 只是确保 DNS 查询响应指向合法服务器。
对于经过验证的拒绝存在，NSEC 或 NSEC3 记录可证明所查询的名称或类型不存在。解析器会收到加密签名的证明，显示区中确实存在哪些名称，从而确认查询的名称会出现在哪个空格中。
DNSSEC 资源记录的实践
让我们更详细地了解与 DNSSEC 相关的主要 DNS 记录类型。
RRSIG 记录使用区的私人密钥生成，通常是普通记录的 ZSK。每个签名都指定了签名算法（如 ECDSAP256SHA256）、签名名称中的标签数、原始 TTL 和开始/到期时间戳。这些时间戳至关重要：解析器会拒绝超出有效期窗口（通常设置为 30 天）的签名。区域操作员必须在过期前退出记录，以避免验证失败。
DNSKEY 记录出现在区域顶点，在滚动期间可能包含多个密钥。标志字段可区分密钥的作用：257 表示设置了 SEP（安全入口点）位的 KSK，而256 表示 ZSK。密钥标签是根据密钥数据计算得出的 16 位标识符，可帮助解析器快速匹配 DNSKEY 记录和相应的 DS 记录。
父区域中的DS 记录包含子区域 KSK 的哈希值。典型的 DS 记录包括密钥标签、算法编号、摘要类型（通常为 SHA-256）和摘要本身。 在 DNSSEC 验证过程中，解析器会获取子 DNSKEY、计算哈希值并进行比较。不匹配会产生 BOGUS 状态，导致验证失败。
NSEC 记录按规范排序顺序排列区域名称。每个 NSEC 都指向下一个现有名称，并列出该名称的记录类型。 这证明了区的不存在，但却暴露了区的内容，使攻击者可以通过跟踪链来枚举每个名称。
NSEC3通过对名称进行散列处理，并在链式处理前加入盐和迭代次数，来解决区域行走问题。虽然这可以防止琐碎的枚举，但意志坚定的攻击者仍然可以离线破解可预测的名称。选择退出标志允许在已签名的区域内使用未签名的授权，这对拥有许多未签名子域的大型区域非常有用。
CDS 和 CDNSKEY 记录是 DS 和 DNSKEY 格式的镜像，但发布在子区域本身。父区域操作员可以轮询这些记录，自动更新授权签名者记录，从而简化密钥滚动和 DNSSEC 初始部署。
分组 DNS 记录
DNSSEC 实施的一个基本方面是将 DNS 记录分组为资源记录集 (RRSets)。 RRSet 是区域内共享相同名称和类型的 DNS 记录的集合。 DNSSEC 使用单个 RRSIG 记录对整个 RRSet 进行签名，而不是对每个记录进行签名。 这种方法简化了 DNS 数据的签名和验证过程，提高了域名所有者和验证解析器的效率。
将 DNS 记录分组到 RRSets 中不仅简化了 DNSSEC 的实施，还增强了 DNS 基础设施的可管理性。当对 RRSet 中的任何记录进行更改时，整个记录集都要重新签名，以确保所有相关 DNS 数据的完整性和真实性得到维护。对于域名所有者来说，这意味着降低了管理签名的复杂性，并能更有效地防止对其 DNS 记录的篡改或未经授权的更改。归根结底，DNS 记录分组是支持现代 DNS 基础设施可扩展性和安全性的最佳做法。
区签名密钥、签名模式和密钥管理
DDNSSEC密钥管理集中于两个不同的角色。 区签名密钥 (ZSK)负责区数据-A、AAAA、MX、TXT 和其他常规记录的日常签名。密钥签名密钥 (KSK)的作用虽然有限，但却非常重要：它只对 DNSKEY RRSet 进行签名，从而创建与父区 DS 记录的可信链接。
运营商将这些角色分开是有充分理由的。ZSK 私钥使用频繁，面临的暴露风险较高，因此每 30-90 天轮换一次，可限制外泄可能造成的损失。KSK 变化很少，每年一次或更少，因为每次轮换都需要更新父区域中的 DS 记录，通常需要注册商的协调。
DNSSEC 的实施主要有三种签名模式：
- 离线签名：在空气屏蔽机器或 HSM 上签署区域，然后将签署的区域文件传输到权威服务器。最适用于安全性大于操作便利性的静态区域。
- 集中在线签署：专门的签名服务接收未签名的更新，并在分发到权威 DNS 服务器之前对其进行签名。兼顾安全性和对动态更新的支持。
- 即时签名：权威服务器在 DNS 请求到达时实时生成 DNSSEC 签名。适合高度动态的区域，但如果服务器被入侵，则会增加密钥暴露风险。
密钥翻转需要谨慎选择时机，以避免破坏信任链。 标准方法是预先发布新密钥：将新密钥添加到 DNSKEY RRSet，等待缓存过期（通常是两个 TTL 期），然后退役旧密钥。 对于 KSK 翻转，在删除旧 KSK 之前，新 DS 还必须通过父区域传播。
2018 年根 KSK 的滚动说明了其中的利害关系。尽管做了大量准备工作，但仍有约 0.3% 的解析器未能更新其信任锚，出现了暂时的 SERVFAIL 响应。对于单个区域来说，这种错误可能看起来微不足道，但对于受影响的用户来说，它们实际上会导致域名离线。
授权签字人
授权签名者（DS）记录是 DNSSEC 信任链的基石，在 DNS 层次结构中将子区域的安全性与其父区域联系起来。DS 记录包含子区域密钥签名密钥（KSK）的加密散列版本，并在父区域中发布。这样，递归解析器就能验证子区域提供的 DNSKEY 记录是否真实，是否被篡改。
通过建立这种连接，DS 记录使域名所有者能够将信任从父区域向下延伸到自己的 DNS 数据，确保解析过程中的每一步都经过验证。这种机制对于维护整个 DNS 基础设施的完整性至关重要，因为它可以防止攻击者在链中的任何一点注入欺诈性 DNS 数据。对于域名所有者来说，正确配置授权签名者记录是部署 DNSSEC 和保护其域名免受基于 DNS 的攻击的关键一步。
DNSSEC 的优点和局限性
DNSSEC 的主要价值在于抵御 DNS 缓存中毒和 DNS 欺骗攻击。通过加密证明响应的真实性，它可以防止攻击者悄无声息地将用户重定向到钓鱼网站或通过虚假的 MX 记录拦截电子邮件。 2008 年的 Kaminsky 漏洞显示了此类攻击的破坏性；DNSSEC 从根本上使这些攻击对已签名的区域无效。
除基本保护外，DNSSEC 还支持高级安全应用。 DANE（基于 DNS 的命名实体验证）允许域名所有者使用 TLSA 记录直接在 DNS 中发布 TLS 证书信息。这可以验证 SMTP 服务器或网络服务的证书，而无需完全依赖传统的证书颁发机构。此类应用需要经过验证的 DNS 数据，而这正是 DNSSEC 所能提供的。
了解其局限性也同样重要：
- 不保密：DNSSEC 验证但不加密。DNS 查询和 DNS 查询响应对观察者仍然可见。 加密需要使用 TLS 或 HTTPS DNS。
- 无 DDoS 保护：DNSSEC 无法阻止针对 DNS 基础设施的大规模攻击。事实上，较大的签名响应可能会加剧放大攻击。
- 无法防范看似合法的威胁：DNSSEC 无法防止错别字抢注或用户误信合法注册和正确签名的域名。
性能方面的考虑包括 DNS 响应明显增大– 每个 RRSet 的 签名大约增加500 字节。这有时会触发TCP 回退（增加延迟）并增加带宽消耗。与普通 DNS 相比，使用 DNSSEC 的开放解析器可将反射攻击放大 50 倍或更多。
尽管有这些权衡，包括 ICANN 和 NIST 在内的安全组织还是建议高价值域使用 DNSSEC。开销确实不小，但对于面向公众的服务来说，DNS欺骗可能导致严重的攻击，因此保护的复杂性是合理的。
风险、挑战以及为何采用率仍不均衡
DNSSEC 带来了操作风险，这在很大程度上解释了为何在采用 DNSSEC 时犹豫不决。 配置错误–签名过期、DS/DNSKEY 不匹配或签名链无效–会导致验证失败。 对于大约 30% 正在验证解析器的用户来说，配置错误的区域只会停止工作。 没有优雅的降级；查询会返回 SERVFAIL。
一些障碍导致 DNSSEC 部署缓慢：
- 多方协调：签名要求域名所有者、注册商和 DNS 托管服务提供商协调一致。DS 记录必须通过注册商系统才能到达父区域。
- 专业知识差距：许多组织缺乏 DNSSEC 经验。由于担心配置错误导致故障，他们不敢开始使用 DNSSEC。
- 传统基础设施：有些企业环境包括不完全支持 DNSSEC 验证的解析器或设备，这就产生了兼容性问题。
采用情况统计显示进展不平衡。DNS 根区自 2010 年起开始签署DNSSEC，目前已有 1 400 多个顶级域名支持 DNSSEC。然而，二级域名的采用情况却大相径庭。在注册机构激励措施和强制政策的推动下，.nl 区域的签名率超过 95%。相比之下，.com 的采用率约为 1.5%–数百万个域名仍未签署。
在解析器方面，APNIC 的测量结果表明，全球约有 30% 的 DNS 解析器执行 DNSSEC 验证，高于 2018 年的 10% 左右。进展仍在继续，但大多数最终用户仍会收到未经验证的 DNS 响应。
DNSSEC 还提出了验证失败之外的安全问题。 大量签名响应使权威服务器成为 DNS 放大攻击的目标。运营商必须实施响应速度限制，并遵循解析器配置的最佳实践，以避免在不知情的情况下成为攻击的基础架构。
主要组织继续倡导更广泛地采用 DNSSEC。ICANN 发布了部署指南，国家网络安全机构也越来越多地建议政府和关键基础设施域采用 DNSSEC。预计到 2030 年，随着 CDS/CDNSKEY 的自动化减少操作摩擦，二级域名的采用率将达到 50%。
实际操作：DNS 根区签名仪式和信任锚点
DNS 根区在 DNSSEC 架构中占有独特的地位。由于没有父区提供 DS 记录，根区的 KSK 必须作为最终信任锚点在带外受到信任。做好这一点非常重要–每一个DNSSEC 信任链都源于此。
ICANN 每年要在美国和欧洲的安全设施中举行四到六次根节点签署仪式。这些仪式涉及特殊的程序控制：硬件安全模块（HSM）存储根私人密钥，只有在多名加密官员同时使用智能卡和 PIN 码时才能访问。物理保障措施包括防篡改袋、监控保险箱和完整的视频记录。
2010 年 7 月首次根区签署标志着 DNSSEC 从理论过渡到全球实际部署。 2018 年的 KSK 翻转–用 KSK-2016 取代了原 2010 年的 KSK–考验了系统更新基本信任锚的能力。 尽管开展了广泛的外联活动，但仍有约 0.2% 的解决者因软件或配置过时而遇到问题。计划在 2020 年代中期进行未来的升级。
递归解析器通过软件分发或由 IANA 维护的自动更新协议获取根信任锚。 现代解析器软件通常包含当前锚点和获取更新的机制，确保信任链在密钥发生变化时保持不变。
这些仪式看似繁琐，但却提供了合理的保证。根区的完整性是 DNSSEC 在全球范围内的基础，而记录在案、可审计的流程则为这一关键基础设施以适当的严格方式运行建立了信心。
在域名上部署 DNSSEC
准备好为您的域名启用 DNSSEC了吗？ 这一过程包括从验证到持续维护的几个阶段。
确认的先决条件：
- 您的 TLD 支持 DNSSEC（请查看 ICANN 的部署资源）
- 您的注册商接受 DS 记录提交
- 您的 DNS 托管服务提供商支持区域签署和 DNSKEY 管理
许多托管 DNS 提供商（如Cloudflare和AWS Route 53）会自动处理签名。对于自我管理的区域，您需要与权威服务器软件兼容的签名工具。
典型部署步骤
- 生成 ZSK 和 KSK 对（或启用提供商管理的签名）
- 在本地签署 DNS 区域并验证 DNSSEC 签名
- 发布 DNSKEY 记录（以及用于自动 DS 管理的 CDS/CDNSKEY 选项）
- 通过注册商界面提交 DS 记录
- 留出传播时间，然后验证完整的链条
验证同样重要。如果您的组织使用递归解析器，请启用 DNSSEC 验证（如 BIND 中的dnssec-validation yes ）。针对已知域进行测试：正确签名的网站应返回AD（验证数据）标志，而dnssec-failed.org 则应返回SERVFAIL。
最佳操作实践：
- 监控签名过期：RRSIG 的有效期通常为30 天。在到期前自动退出。
- 测试关键滚转：在生产前，在暂存环境中练习翻转程序。
- 实施警报：配置对解析器 DNSSEC 验证失败的监控。
- 记录程序：清晰的运行手册可防止在发生事故或计划翻转时出现恐慌。
具体的界面因注册商和提供商而异，因此应重点了解基本任务，而不是记住具体的按钮点击。我们的目标是在部署 DNSSEC 的同时不造成中断–精心的准备和测试将使这一目标成为可能。
DNSSEC 最佳实践
成功部署 DNSSEC 不仅仅需要启用签名，还需要持续关注细节并遵守行业最佳实践。域名所有者应优先考虑定期轮换密钥，以最大限度地降低密钥泄露的风险，并确保所有私钥的安全存储，最好使用硬件安全模块或其他受保护的环境。
对 DNSSEC 验证进行持续监控至关重要；这包括跟踪签名到期日期，并在记录失效前及时退出。同样重要的是，要验证DNS 基础设施的所有组件（授权服务器、递归解析器和注册商接口）是否完全支持 DNSSEC 的实施和验证。
测试是另一个关键步骤。 域名所有者应使用工具和测试域模拟成功和失败的验证情况，定期检查其 DNS 数据是否被正确签名和验证。 通过遵循这些最佳实践，域名所有者可以维护弹性 DNS 基础设施，保护其用户免受基于 DNS 的攻击，并确保其域名系统的持续完整性和可信度。
结论和下一步措施
DNSSEC 将域名系统从信任一切的架构转变为通过数字签名和分级信任链进行加密验证的架构，解决了自20 世纪 80 年代设计 DNS 以来一直存在的漏洞。保护机制–RRSIG 签名、DNSKEY/DS 链接以及通过 NSEC/NSEC3 进行验证的拒绝–防止了 DNS 缓存中毒和 DNS 欺骗攻击，否则这些攻击可能会悄无声息地重定向用户。对于包含欺诈性 DNS 数据的现有 DNS 记录，验证解析器只需完全拒绝受操纵的 DNS 数据即可。
尽管操作复杂，但DNSSEC 自 2010 年根签名以来已显著成熟。广泛的顶级域名支持、通过 CDS/CDNSKEY 提高的自动化程度以及不断增长的解析器验证率都表明了这一发展势头。主要的安全组织都认可 DNSSEC 适用于欺骗可能造成严重危害的域名。
对于 DNS 基础设施的负责人来说，接下来的实际步骤包括
- 清点当前已签署的域和区
- 计划从面向公众的关键服务开始，分阶段部署 DNSSEC
- 在可行的情况下，在内部解析器上启用 DNSSEC 验证
- 建立 DNSSEC 故障监控和事件响应程序
进一步的学习资源包括核心 DNSSEC RFC（4033、4034、4035）、ICANN 和地区网络信息中心提供的部署指南，以及威瑞信 DNSSEC Analyzer 等测试工具。从理解到行动的路径比以往任何时候都更加清晰–安全效益证明了投资的正确性。