DNS 根密钥完成轮换：网站打不开时，怎样判断是不是解析问题？
文章目录
10 月 11 日，DNS 根区开始使用新的密钥签名密钥 KSK-2024，标识为 38696。这不是某个机场更换节点，也不是网站统一更换 HTTPS 证书，而是 DNSSEC 信任链的一次计划内轮换。
IANA 表示，多数用户不应受到影响；没有更新信任锚的 DNSSEC 验证解析器，可能遇到验证失败。ICANN 随后确认轮换按计划完成，并表示仍在评估少量系统的问题报告与轮换之间的关系。因此，不能把这件事写成“全球 DNS 大面积故障”，也不能将这几天所有访问异常都归因于它。IANA 通告与ICANN 后续通告说明了这个范围。
新密钥影响的是哪一环
输入域名后，设备需要获得对应地址。执行 DNSSEC 验证的递归解析器，会根据签名和信任锚验证 DNS 数据。根区 KSK 是这条验证链上的基础之一。
如果解析器仍只信任不适用的旧密钥，验证可能失败。此时网络本身未必断开，代理连接也未必失败，但应用拿不到有效解析结果，表现仍可能是网页打不开。
这里的对象是“执行验证的解析器”。使用公共 DNS、运营商 DNS，还是在路由器上自建解析服务，维护责任和检查方式并不相同。普通用户通常不需要在电脑上手工安装根区密钥。
为什么节点测速正常，网页仍可能失败
节点延迟测试、DNS 查询和实际网站访问，可能不是同一条请求。测试目标可达，并不能证明应用使用的解析器也能完成所有域名查询。
反过来，一个网站打不开也不能直接证明 DNSSEC 出了问题。站点本身故障、路由规则、代理出口、证书错误和本机配置都可能产生相似体验。先区分失败发生在哪一步，再判断是否与密钥轮换有关。
普通用户先检查什么
先记录具体域名、错误提示、发生时间和所用网络。然后确认设备实际使用哪一个解析器；有些客户端有独立 DNS 配置，浏览器也可能使用自己的加密 DNS，不能只检查网卡上的地址。
用同一个网络、同一个域名比较不同解析路径。如果只有某个解析器持续失败，而其他已知正常的解析器能返回结果，问题范围才缩小到该解析路径。比较过程中保留原设置，避免同时修改节点、规则和 DNS。
如果服务由运营商、公共 DNS 或机场维护，将域名、时间、解析器与报错提供给对应维护方即可。不要把购买新订阅当作修复 DNS 验证的必经步骤。
维护本地解析器的人怎样定位
可以先检查返回状态。下面是只读诊断示例，把地址替换为自己维护的解析器：
dig @127.0.0.1 example.com A +dnssec
dig @127.0.0.1 example.com A +dnssec +cdflag
第一条请求 DNSSEC 相关数据；第二条带上检查禁用标志，供支持该行为的解析器诊断。返回差异可以作为线索，但单个域名、两次查询不足以确认是根信任锚的问题。解析器可能有缓存、转发与本地策略，仍需结合日志和软件状态核对。
不要因为第二条有结果就长期关闭 DNSSEC 验证。那只是绕过了一项检查，并没有修复信任锚或验证配置。
真正需要核对的是信任锚和更新机制
ICANN 提醒解析器运营者确认 KSK-2024 是否存在于信任锚配置中，不要假设自动更新一定已经成功。缺失时，应按所用解析器厂商的指引检查更新机制和信任锚，而不是复制网上一段来源不明的密钥。轮换状态与维护提醒提供了后续入口。
Cloudflare 在轮换前也发布了技术说明。这类文章适合了解机制，但判断轮换后的实际状态，应同时核对 IANA 和 ICANN 的后续通告，不能继续把轮换前的预告当作当前故障结论。
与代理客户端故障怎么区分
解析失败、代理连接超时和客户端配置错误需要分别记录。若日志已经显示配置字段不受支持，就先处理配置；若节点可连接但域名查询失败，再沿着解析路径检查。
本站另有sing-box 旧 DNS 配置迁移和连接检查教程。两者分别处理格式变化和一般连接排查，不将任何一种现象直接写成机场停运。