01 · 验证解析器（Validating Resolver）的角色
经典DNS中，递归解析器只负责"取回应答"；DNSSEC下，它还需作为验证方，沿链式信任校验从根到叶的每一段签名，并据结果决定如何把应答交回终端。验证解析器是DNSSEC"闭环"的最后一公里，也是本专题子课题01（劫持检测）判定应答真伪的核心执行者——一条经验证为Secure的应答，即可在"应答被伪造/篡改"层面被信任。
02 · EDNS0 DO位与 AD 标志
DNSSEC依赖两个关键协议位（RFC 3225/6891）：
- DO（DNSSEC OK）位：客户端在查询中置DO=1，告知服务器"我（或我的验证器）能处理DNSSEC记录"，服务器据此在应答中携带RRSIG/DNSKEY/NSEC等。
- AD（Authentic Data）标志：由验证解析器在"整条链验证通过"的应答中置位，告知下游"此应答经DNSSEC验证为真"；但终端Stub解析器与链路若不信任，不应盲目依赖AD（"最后一段"信任问题）。
- CD（Checking Disabled）位：客户端可置CD=1请求"禁用验证"，用于诊断（取回即便Bogus的原始数据）。
"最后一段"信任缺口：DNSSEC验证多在递归解析器完成，终端Stub往往通过不加密的本地链路接收结果并依赖AD标志。若本地链路不可信，AD可能被篡改。缓解方式包括：终端自行验证（代价高）、以DoT/DoH把"终端↔递归"段加密并信任所选递归、或在企业内网部署受控验证解析器（见子课题03）。
03 · 验证状态机（RFC 4035 / 5155）
验证器对每个RRset给出四类结果，直接决定解析器行为：
| 状态 | 含义 | 解析器行为 |
|---|---|---|
| Secure | 沿链验证通过，数据真实完整。 | 应答返回，AD标志可置位。 |
| Insecure | 该区/名未签名（无DNSSEC覆盖），无法验证。 | 应答按普通（未验证）数据返回。 |
| Bogus | 验证失败（链断裂/签名无效/被篡改）。 | 拒绝应答（SERVFAIL），不返回伪造数据。 |
| Indeterminate | 无法确定（如请求本身未要求DNSSEC或缺少必要数据）。 | 按Insecure处理。 |
Bogus的"硬失败"特性：这是DNSSEC的双刃剑——它确保伪造数据绝不被接受，但任何配置错误（父DS不匹配、签名过期、大包被丢）都会让本应可达的域名被解析器判Bogus并返回SERVFAIL，造成"部署DNSSEC反而断网"的事故（NASA、HBO Now等历史案例）。因此验证部署必须"先验证后依赖"（第6页）。
04 · 根信任锚与 RFC 5011 自动更新
根信任锚是链式信任的起点。根区自2010年首次签名（KSK-2010），现行锚为KSK-2017：
- 根KSK滚动时间线：原计划2017-10-11轮转，因RFC 8145信号显示大量解析器尚未就绪而推迟；2018-10-11根DNSKEY RRset改由KSK-2017签署；旧锚于2019-01-11撤销。整个过程以"极小中断"完成（ICANN复盘结论）。
- RFC 5011 自动接纳：验证器（如BIND managed-keys）见到新信任锚并持续观察后，约30天自动接纳为新锚；在接纳完成前不得撤旧锚，否则依赖旧锚的解析器失联。
- 硬编码回退：现代解析器软件（BIND 9.11+、Unbound等）内置当前根锚，新装即具备正确信任锚，显著降低运维门槛。
启示：根滚动的成功得益于"预发布+长接纳窗口+自动化"，其经验直接支撑本课题第4页的轮转时序模型与应急原则——任何KSK轮转都不可压缩RFC 5011接纳窗口。
05 · 主流验证解析器配置
| 解析器 | 开启验证方式 | 信任锚管理 |
|---|---|---|
| Unbound | dnssec: yes（默认开启验证）。 | 内置根锚（root.hints/root.key），支持RFC 5011自动更新。 |
| BIND | dnssec-validation auto;（自动信任锚）。 | managed-keys 自动接纳；亦支持trusted-keys手动。 |
| Knot Resolver | 默认开启DNSSEC验证（validator模块）。 | 内置根锚，RFC 5011自动更新。 |
| 公共DNS | Cloudflare 1.1.1.1、Google 8.8.8.8、Quad9 9.9.9.9 等均支持验证。 | 由服务商统一维护根锚。 |
配置片段为说明性要点；具体语法与版本差异以各软件官方文档为准。本课题不提供面向未授权系统的配置脚本。
06 · 验证率测量（APNIC 口径）
APNIC Labs通过广告网络注入的DNS测量，估算"处于开启DNSSEC验证的递归解析器之后的用户比例"。近年全球约三分之一（约34%），但区域差异显著：
| 国家/经济体 | 验证率（约） | 说明 |
|---|---|---|
| 芬兰 FI | ~95% | 大型ISP普遍开启验证，全球最高之列。 |
| 丹麦 DK / 瑞典 SE / 挪威 NO | ~87–89% | 北欧多国ISP默认开启验证。 |
| 德国 DE | ~67% | 多家大型运营商开启。 |
| 荷兰 NL | ~59% | SIDN长期推动的成效体现。 |
| 美国 US | ~35% | Comcast等运营商开启带动整体。 |
| 法国 FR / 英国 GB | ~34% / ~10% | 英国明显偏低，差异显著。 |
国家数值为SIDN（2023年初，《Majority of Dutch domains and internet users have DNSSEC security》一文）引用APNIC Labs 2022年12月测量给出的数值；随统计时点波动，引用须以APNIC Labs（stats.labs.apnic.net/dnssec）最新国家数据为准。本表用于说明"国家间差异显著（最高FI约95% vs 最低GB约10%）"。
验证率 ≠ 部署率：APNIC约34%用户处于验证解析器之后，但Cloudflare数据显示仅约3.2%的入向查询发往已签名域名，二者相乘得出"实际被验证的查询约1%"——因为绝大多数顶级站点（google.com、wikipedia.org等）自身未签名。提升验证"实益"的关键是推动重要域名自身签名（第7、8页）。
07 · Aggressive NSEC 缓存（RFC 8198）
DNSSEC的否定应答（NSEC/NSEC3）覆盖一段"不存在区间"，RFC 8198允许验证解析器利用已验证的否定证明在缓存中合成同区间的其他否定应答，从而：
- 减少向权威的重复查询，缓解NSEC带来的查询放大；
- 在不增加网络往返的前提下提升否定应答验证性能；
- 使"开启DNSSEC"对性能的影响可控，利于验证解析器普及。
与NSEC3参数的联动：若NSEC3盐值固定、迭代次数过低，攻击者仍可能离线还原区间内的域名；Aggressive NSEC缓存本身不解决枚举风险，须与第2、3页的NSEC3参数治理配合。
本节参考来源（第5页）
以下为真实可查的权威来源，支撑本页关于验证状态、根信任锚、解析器配置与验证率的事实表述。
RFC 4035 — Protocol Modifications for DNSSEC（验证状态机/DO/AD）：rfc-editor.org/rfc/rfc4035
RFC 6891 — EDNS0（DO位现行规范，STD 75）：rfc-editor.org/rfc/rfc6891
RFC 5011 — Automated Updates of DNSSEC Trust Anchors（30天接纳）：rfc-editor.org/rfc/rfc5011
RFC 8145 — Signaling Trust Anchor Knowledge（2017，根轮转准备度信号）：rfc-editor.org/rfc/rfc8145
ICANN — Review of the 2018 DNSSEC KSK Rollover：icann.org/.../review-2018-dnssec-ksk-rollover.pdf
RFC 8198 — Aggressive Use of DNSSEC-Validated Cache：rfc-editor.org/rfc/rfc8198
APNIC Labs — DNSSEC Validation Measurement：stats.labs.apnic.net/dnssec
APNIC Blog — "Calling time on DNSSEC?"（2024-05-28，验证率/签名域名统计）：blog.apnic.net/2024/05/28/calling-time-on-dnssec