01 · 全球部署概览
从"根—TLD—二级域"三层看，DNSSEC的覆盖呈现"上密下疏"的明显梯度：
- 根区：自2010年首次签名，现行信任锚为KSK-2017（2018年轮转），全链路起点已就绪。
- TLD/ccTLD：绝大多数主流通用与国别顶级域已完成委派签名（在根区发布DS），如Verisign运营的根与.com/.net、以及大量ccTLD；以.nl为例，CNNIC/SIDN统计显示其超过60%的域名已签名。
- 二级域（业务侧）：落地明显偏弱且高度不均。APNIC对Tranco前100万域名的扫描显示约9.4%有效签名；.com截至2024年仅约5%域名签名（Verisign公开数据口径）；而google.com、wikipedia.org等绝大多数顶级站点自身未签名。
- 高部署TLD梯队：部分ccTLD/行业域显著高于均值——如.nl近60%（SIDN，2023年初）、瑞典.se约48%（IIS/The Swedish Internet Foundation口径）、.br、.is、.se等北欧国家长期居前；这说明注册局侧推动（默认签约/批量工具/资费激励）能有效改变二级域签名率。
统计口径与时点不同，数值间不可直接横向相减；本页仅作量级说明，引用须注明来源并核对最新数据。
02 · 验证率与"部署—验证"落差
更关键的是"区已签名"与"查询被验证"之间的巨大落差（详见第5页）：APNIC测量显示约34%用户处于开启验证的递归解析器之后，但Cloudflare数据显示仅约3.2%的入向查询发往已签名域名，二者相乘得出"实际被验证的查询约1%"。
落差的本质：绝大多数用户虽"有可能"被验证，但因所访问的域名未签名，DNSSEC的真实保护并未触发。提升DNSSEC实际价值的关键，是让高频访问的重要域名自身签约（第8页路线图将讨论如何分优先级推进）。
03 · 部署障碍分析
APNIC首席科学家Geoff Huston等长期指出，DNSSEC采用偏低主要不是技术问题，而是经济与运维结构问题：
| 障碍 | 机理 |
|---|---|
| 收益不在应用层 | DNSSEC是基础设施级真实性保障，但应用（浏览器/App）通常无法感知"应答是否被验证"，仍须自做认证（如TLS），导致应用侧缺乏部署动机。 |
| 成本高、第三方多 | 部署要求父链全签、权威存储签名、解析基础设施支持更大应答与TCP回退，多方（注册商/注册局/运营者）各自承担增量成本却难直接获益。 |
| "全有或全无"风险 | 误配即Bogus断网（NASA、HBO Now等案例），运维者顾虑 outage 与声誉风险，倾向不签。 |
| 大厂未签名 | 最高频访问的站点普遍未签，拉低了全网"被验证"比例，形成负向示范。 |
| 运维复杂 | 密钥生成、DS同步、轮转、监控需专业能力；中小运营者门槛高（CDS自动化正在缓解）。 |
辩证看待：障碍真实存在，但DNSSEC在"防御缓存投毒/国家级重定向/关键基础设施解析保护"场景仍有不可替代价值；本课题主张"分场景、分优先级"推进——对金融、政务、关键基础设施域名优先签约并自验证（第8页）。
04 · 与加密 DNS（DoH/DoT/DoQ）的协同
DNSSEC与加密DNS常被混淆，二者目标正交、可叠加：
| 能力 | DNSSEC | DoT/DoH/DoQ |
|---|---|---|
| 真实性/完整性 | ✅ 核心目标（签名验证） | ❌ 不直接提供 |
| 机密性 | ❌ 不加密应答 | ✅ 加密"终端↔递归"段 |
| 抗链路篡改 | ✅ 篡改会被判Bogus | ✅ 加密使链路难篡改 |
| 最后一段信任 | ⚠ 依赖递归正确验证与AD可信 | ✅ 加密+信任所选递归 |
本专题子课题03（加密DNS评估）即研究DoH/DoT/DoQ的隐私与管控；本子课题与之一致的结论是：以加密DNS保障"终端↔递归"段机密性与抗抢答，以DNSSEC保障"递归↔权威"段及整链真实性，二者互补构成"机密+真实"的双重防护。企业内网可部署受控验证解析器 + 加密上行，兼顾安全、隐私与可审计（呼应子课题03的管控网关）。
05 · 国内视角（CNNIC 与国密算法）
我国在网络基础资源安全领域持续推进自主可控：
- RFC 9563（SM2/SM3 for DNSSEC）：由中国互联网络信息中心（CNNIC）制定的《域名服务系统安全扩展（DNSSEC）中的SM2算法》，于2024年由IETF发布，首次将国密SM2数字签名与SM3杂凑算法引入DNSSEC，并规定了算法号17及SM3的DS摘要类型（值6）。这是我国在互联网基础资源领域标准的重要突破。
- 实现与生态状态：RFC 9563为独立提交（Independent Submission，无IETF共识），且明确指出"多数实现可能尚不支持SM2/SM3"，故当前算法17在IANA注册表中为MAY级、并非广泛支持——选用前须确认解析器与验证器链路的互操作性与接受度。
- 合规衔接：国内关键信息基础设施的DNSSEC部署，须结合《关键信息基础设施安全保护条例》与等保2.0等要求；国密算法的引入为"自主可控"提供选项，但落地仍受生态成熟度制约。
严谨提示：本页所述RFC 9563与算法17状态均来自CNNIC官方发布与RFC Editor文档；关于".cn是否已全量签名的当前状态"以CNNIC/ICANN权威公告为准，本课题不臆测具体比例与日期。
06 · 生态趋势
- CDS/CDNSKEY 自动化普及：越来越多注册局/注册商支持自动DS同步，显著降低轮转与部署错误（第3、4页）。
- 算法演进：ECDSA P-256与Ed25519成为新建署主流，SHA-1系退出，国密SM2/SM3（RFC 9563）提供自主选项（第2页）。
- 验证解析器普及：Inline-signing与内置根锚使验证解析器（Unbound/BIND/Knot/公共DNS）更易开启，验证率缓慢上升。
- DANE/TLSA 应用：邮件（SMTP）领域的DANE（RFC 6698）基于DNSSEC绑定证书，是对抗伪造证书的有效补充（本课题仅在应用层关联，不展开实现）。
- 测量驱动：APNIC/ICANN/ISOC Pulse持续公开测量，使"部署—验证"落差可被量化与追踪，倒逼重点域名签约。
本节参考来源（第7页）
以下为真实可查的权威来源，支撑本页关于部署统计、障碍分析、加密DNS协同与国内RFC 9563的事实表述。
APNIC Blog — "Calling time on DNSSEC?"（2024-05-28，部署/验证率、障碍分析）：blog.apnic.net/2024/05/28/calling-time-on-dnssec
APNIC Labs — DNSSEC Validation Measurement：stats.labs.apnic.net/dnssec
SIDN Labs — DNSSEC adoption（.nl 统计）：stats.sidnlabs.nl/en/dnssec.html
SIDN — "Majority of Dutch domains and internet users have DNSSEC security"（2023年初；.nl近60%签名、APNIC全球约30%验证率及欧洲国家验证率表）：sidn.nl/en/news-and-blogs/majority-of-dutch-domains-and-internet-users-have-dnssec-security
Internet Society Pulse — DNSSEC Adoption/Validation：pulse.internetsociety.org
CNNIC — 《域名服务系统安全扩展(DNSSEC)中的SM2算法》RFC 9563 发布（2024-12-13）：cnnic.net.cn/n4/2024/1213/c208-11193.html
RFC 9563 — SM2 Digital Signature Algorithm for DNSSEC（算法17，CNNIC，2024）：rfc-editor.org/rfc/rfc9563
RFC 6698 — DNS-Based Authentication of Named Entities (DANE)：rfc-editor.org/rfc/rfc6698