Cloudflare开启DNSSEC后网站打不开？排查步骤与解决方案

最近在折腾网站部署时，遇到了一个挺让人郁闷的问题：两个域名都解析到了同一个IP，其中一个没开启DNSSEC的域名访问一切正常，可偏偏开启DNSSEC的那个，虽然ping能通，解析也成功，但浏览器就是死活打不开网站。这到底是怎么回事？今天就来聊聊这个问题的排查思路和可能的原因。

问题现象分析

这种情况其实不算罕见。首先，我们要明确几个关键点：

1. 解析成功：说明基础的DNS配置（A记录、CNAME等）没有问题。
2. Ping通：说明网络层面的IP路由也是通的。
3. 打不开网页：问题通常出在HTTP/HTTPS握手或者更深层次的DNS验证上。

既然开启了DNSSEC（域名系统安全扩展），它会对DNS数据进行数字签名，以防止DNS劫持。但这也意味着，如果签名链路出现任何一点瑕疵，解析器可能会直接拒绝响应，导致解析失败或者连接建立失败。

可能的原因与排查步骤

1. 检查DS记录是否正确上传到注册商

这是最常见的一步坑。Cloudflare生成DNSSEC后，会给你一段DS记录（Delegation Signer）。你必须把这段完整、准确的记录复制到你域名购买处（注册商）的DNSSEC管理后台。

• 常见错误：复制时少了空格、多了一个字符，或者标签类型搞错了（比如选了SHA-1而不是SHA-256）。
• 排查方法：去注册商后台核对，确保与Cloudflare控制台显示的完全一致。如果之前已经上传过，试着删除重新添加，有时候注册商系统同步会有延迟。

2. NSEC/NSEC3 设置冲突

Cloudflare默认使用NSEC3来证明“不存在”的域名。如果你的上游DNS提供商或者注册商强制要求或默认使用了NSEC，可能会导致验证链断裂。

• 解决方案：在Cloudflare的DNS设置里，检查“DNSSEC”状态页。有时候重新禁用再启用DNSSEC，或者调整NSEC设置（如果选项开放），可以刷新签名状态。

3. 本地或ISP DNS缓存问题

虽然你觉得解析成功了，但可能你的本地电脑或者运营商的DNS服务器还缓存着旧的状态（未签名的状态）。当新的DNSSEC请求过来时，可能会出现验证不通过的情况。

• 尝试操作：
  • 在命令行执行 ipconfig /flushdns (Windows) 或 sudo systemd-resolve --flush-caches (Linux) 清空本地缓存。
  • 修改电脑DNS为公共DNS（如 8.8.8.8 或 1.1.1.1）再试，绕过运营商的DNS。

4. 防火墙或WAF规则拦截

开启DNSSEC后，DNS数据包的大小会增加（因为带了签名信息）。有些老旧的防火墙或者严格的WAF（Web应用防火墙）策略可能会误判这些大的UDP包为攻击流量而直接丢弃。

• 排查思路：暂时关闭Cloudflare的防火墙功能（Under Attack Mode等），或者检查源站服务器的防火墙日志，看是否有关于EDNS0（Extension Mechanisms for DNS）被拦截的记录。

5. SSL/TLS 证书问题

虽然这与DNSSEC不直接相关，但在实际排查中容易被忽略。如果开启了SSL（Full或Full Strict）模式，而你的源站证书配置有误，或者证书链不完整，浏览器在DNS解析正确的情况下，依然会在握手阶段失败。

• 验证方法：在Cloudflare的SSL/TLS设置里，先临时改为“Flexible”模式。如果这时候能打开网站，说明问题出在源站证书上，而不是DNSSEC。

终极排查工具推荐

如果以上步骤还没解决，别急着放弃，用这几个工具测一下，往往能直接定位问题：

• DNSViz (https://dnsviz.net/)：这个工具能生成一张完整的DNS签名链图谱，哪一步断了一目了然。只要输入域名，它就会告诉你是在签名验证还是链条连贯性上出了问题。
• dig 命令：如果你熟悉命令行，可以用 dig +dnssec yourdomain.com 查看返回的DNSSEC标志位（AD flag）是否设置。

总结

开启DNSSEC是提升域名安全的好习惯，但配置过程确实比普通DNS要繁琐。遇到“解析通但打不开”的情况，90%的问题都出在DS记录同步和DNS缓存上。

建议大家在操作时，一旦开启DNSSEC，就先不要动其他DNS设置，等待48小时让全球DNS服务器完全同步。如果还是不行，老老实实用DNSViz跑一遍图，比瞎猜管用多了。

希望这篇排查笔记能帮到遇到同样坑的朋友，如果你有其他奇葩的解决思路，欢迎在评论区分享！