同一个地址打开却结果不同：DNSSEC 管什么、不管什么

输入同一个域名，你打开的是官网，他打开的是钓鱼站——这种事故的常见根源在 DNS 解析层：域名到 IP 的映射在到达你的设备前被某个中间环节篡改了。DNSSEC 就是为堵这个洞设计的，但围绕它的误解和它的功能一样多。这篇文章的目标是把“它管什么、不管什么”一次讲清。

先说它管的事。DNS 的原始问题是应答毫无防伪：任何人只要站到了应答链路上，都可以伪造一条“这个域名对应那个 IP”。DNSSEC 的思路是给每条应答记录配上由权威服务器私钥生成的数字签名，并从根区开始逐级建立信任链：根签名验证顶级域密钥，顶级域验证各区域的密钥，区域再验证自己记录上的签名。支持验证的解析器收到应答后会逐层核签，签名对不上就返回验证失败（典型表现是 SERVFAIL）而不是照单全收。一句话：它防的是“应答在传输与缓存环节被篡改或伪造”，让投毒式 DNS 劫持在验证链完整的场景里失效。

再说不管的事，这部分比机制介绍更有实用价值。第一，它不加密。DNSSEC 的签名和查询内容都以大家熟悉的方式走，链路中间人依然能看见你查询了哪些域名——想解决“被看见”的问题，用的是另一套东西：DNS over TLS 或 DNS over HTTPS 这类加密传输。两者一个管真伪、一个管隐身，经常被混为一谈。第二，它不验网站内容。签名保护的是映射关系，不是映射尽头那个站点的质量；一个通过完整 DNSSEC 验证的解析结果，照样可以指向一个合法注册、套着 HTTPS 证书、内容假冒的钓鱼站。防仿冒靠的是域名核验纪律和证书透明度意识，与 DNSSEC 无关。第三，它救不了已经被攻陷的服务器：权威区文件本身被改了，攻击者用真密钥重新签名即可，防伪体系完全正常地“如实”分发恶意结果。

两个容易踩的操作边界。其一是部署不均：DNSSEC 不是全网开关，它取决于你用的解析器和沿途各级区域是否都启用了签名与验证；有的域名签了、你的网络不验，等于没签。所以“这个网站有没有 DNSSEC”永远不如“我的解析链路会不会验证它”重要，配置公共加密解析服务是普通人提升验证覆盖率最省事的一跳。其二是故障处置：签名的区域在签名缺失或过期时会得到 SERVFAIL，看起来像“网站挂了”。网上流传的“网站打不开就关掉路由器 DNSSEC 验证”教程，效果等同于把质检章从流程里撕掉——正确做法是换解析器测试、查询该域的签名状态（公开工具可查），确认是上游签名故障再等待或申诉，而不是从自己设备上关掉验证。

顺手给一套普通用户的十分钟设置流程，把上面的分工翻译成动作：第一步，在手机与电脑的私人 DNS 或加密 DNS 设置里启用一家主流公共解析服务（同时获得加密传输与更高的验证覆盖率）；第二步，路由器上关闭“运营商默认 DNS”的自动恢复选项，避免设备设置被固件更新悄悄改回；第三步，用在线工具抽查你常去的几个交易类域名的 DNSSEC 状态，了解你所在链路的实际保护面——注意这是了解边界，不是安装软件；第四步，给最重要的三五个站点建浏览器书签并只用书签进入。这套动作不需要你理解密码学细节，却把“解析被篡改”这类低概率高损失事件的概率再压低一层。

和加密用户最相关的一条边界在这里：交易所和钱包 App 打开的是不是真站，取决于“解析对不对”（DNSSEC 管一段）加“站点是不是它自称的那个”（谁都不全自动管）。DNSSEC 提高的是攻击成本，不是安全承诺。把它和加密 DNS、地址核对、书签直连组合成一套分层习惯——书签直连重要站点、加密与验证设置齐全、对搜索结果和广告位入口保持默认怀疑——解析层的坑基本就踩不全。