菜单

首页

全部入口

外观

位置:🇺🇸 美国
主站 gistwillan.top
返回博客
DNS 安全 · 8 分钟

DNS 的两层保护:DNSSEC 保完整性,加密 DNS 保机密性

它们解决的是不同问题,却经常被混为一谈:一个证明答案没被改过,另一个把问题藏起来。没有哪个能同时做到两件。

AMS-IX 机房里的一台 k.root-servers.net 节点
Wikimedia Commons · CC BY-SA 3.0 Wikimedia Commons

DNSSEC 和加密 DNS 总是被放在一起讲,好像它们是同一件事的两个阶段。实际上它们防的是两种完全不同的攻击:DNSSEC 防篡改,加密 DNS 防偷看。一个让伪造的答案无法通过验证,另一个让正确的答案不被路上的任何人看到。代价也不一样——一个是签名过期就全站解析失败,另一个是把你的查询记录集中到少数几家公司手里。分开看清楚,才知道自己的域名需要哪一个。

DNSSEC 信任链与加密 DNS 单跳的对照
一个证明答案没被改过,另一个让问题不被路上的人看到;没有哪个能同时做到。

开 DNSSEC 是少数几种能一次性让整个域名对所有访客失效的 DNS 变更之一,而且失效的样子像是「这个站根本不存在」。协议本身不复杂,复杂的是运维那部分。

一、信任链,四条记录

你的区里有一条 DNSKEY 记录,也就是公钥。区里每一组记录都会带上一条 RRSIG,即用对应私钥对这批数据做的签名。父区发布一条 DS 记录,内容是 DNSKEY 的哈希,正是它把你的区接进全球信任链。验证型解析器从根开始往下走,用 DS 校验你的 DNSKEY,再用这把钥匙校验每一条 RRSIG。任何一环缺失或过期,答案就被拒绝。

「不存在」这件事也是要签名的,用 NSEC 或 NSEC3。所以 DNSSEC 顺带证明了某个名字确实不存在——听起来是个细节,直到你发现它让通配符和空非终端的表现跟大多数人以为的不太一样。

二、谁签名,比签什么更重要

签名可以放在两个地方。DNS 托管商签你的区,你在注册商那边发布 DS;或者注册商两边都做。故障模式永远同一个:父区的 DS 与当前正在签区的密钥对不上。托管商那边开了签名却忘了 DS、迁移 DNS 服务商时旧 DS 留在原地、或者密钥轮换只做了一半,都会造成这个结果。

动手之前先写清楚:DS 归哪一方管,谁有权改它。如果 DNS 托管商和注册商是两家不同公司——这是常态——你就有一个必须按正确顺序执行的两步变更,没有任何面板会替你做。

三、两类最常见的致命错配

  • 区还没真正签名,DS 就先发布了。所有验证型解析器立刻失败,而今天这几乎等于「全网」。顺序要反过来:先签名,用验证器确认,再发 DS。
  • 没人盯着签名过期。有效期 30 天、又不自动续签的区,会在第 31 天、在上一批签名生成的那个时刻挂掉。告警要挂在签名过期上,而不是挂在「DNSSEC 已启用」上。

四、坏掉的时候用户看到什么

不是一个有用的错误页面。验证型解析器返回 SERVFAIL,浏览器把它翻译成笼统的连接失败,工单上写的是「站点挂了」——而你的源站健康、监控一片正常,因为那个监控要么关掉了验证,要么读的是缓存。换一个会做验证的解析器(1.1.1.1、8.8.8.8)测,并且每次变更后都再测一次。

五、密钥轮换,简单说

KSK 轮换意味着:先发布新的 DNSKEY,等到至少 TTL 加传播窗口的时间过去,再换父区的 DS。把这两步挤在同一分钟做完,是典型的自伤式故障。ZSK 轮换代价小、可以自动化,所以多数运营者把 ZSK 交给自动流程,把 KSK 当作需要排期的操作。算法也值得挑:算法 13(ECDSA P-256)的签名比算法 8(RSA/SHA-256)小得多,支持面也够广,今天没有多少理由再选旧的那个。

六、诚实的取舍

DNSSEC 保的是完整性,不是隐私:它证明答案没被篡改,但完全不阻止别人看你查了哪些名字。代价是它增加了一种全局、即时、彻底的故障模式,并且让换服务商变难,因为 DS 也得跟着搬。对一个可用性重要的域名来说,这是真实的成本——值得付,但前提是你已经把监控装好了。

明文 DNS 像一张明信片:路径上任何人都能读上面的地址,而你接入的那个网络,看得到你查过的每一个域名。加密显然是改进。但它也不是人们以为的那种隐私保证——明信片并没有被销毁,只是被转交给了另一个读者。

七、DoH 与 DoT 到底改了什么

DNS-over-TLS 把查询包进一条通往 853 端口的 TLS 连接。DNS-over-HTTPS 把它包进 443 上的 HTTPS,实际效果是看起来像普通网页流量,并且在封掉 853 的网络里照样能用。两种方式下,查询与应答在你设备和解析器之间都是加密的,于是本地网络的运营者——酒店 wifi、运营商、开着抓包的同事——读不到那些域名了。

收益就这么多,而且是真实的。没有改变的是「谁来回答」。解析器依然看得到你问的每一个域名,依然看得到你的 IP,依然能把两者关联起来。你没有消除观察者,只是挑选了一个。

八、集中化的问题

现实中大部分加密 DNS 都流向少数几家大厂,因为浏览器默认就是它们,而用户不会去改默认值。加密之前,你的查询分散在各个网络分配的 ISP 解析器上;加密之后,同一家公司能看到你跨所有网络(咖啡厅、办公室、家里、移动网络)浏览的一大块。原本碎片化的查询日志被合并了,而集中化恰恰是关心隐私的人最该担心的事。

九、没人提醒你的那些坏掉的地方

  • 分离解析失效。只在公司内部能解析的名字,在浏览器坚持使用自己的 DoH 解析器时,会解析不出来,或者更糟——解析成公网上的某个东西。
  • 认证门户打不开。门户需要劫持 DNS 才能弹出登录页;被钉死 DoH 的浏览器只会告诉你网络不通。
  • VPN 的 DNS 策略被绕过。如果系统或浏览器自带加密解析器,流量可能走隧道、查询却走别处——这是字面意义上的 DNS 泄露,而且是由那个「改善隐私」的功能造成的。
  • 过滤消失。家长控制、恶意域名拦截、企业策略都跑在 DNS 上。加密 DNS 要么让它们失效,要么逼它们改做证书中间人,后者更糟。

十、TLS 握手仍然会暴露你

即便查询被加密,今天多数 TLS 连接的 ClientHello 里,SNI 字段依然明文写出你要访问的主机名。Encrypted Client Hello 能补上这个洞,但支持面还很窄,且需要服务端与客户端同时配合——在很多网络里,中间设备看到带 ECH 的连接会直接重置。如果你的担忧是「不该有人知道我刚打开了哪个站」,只加密 DNS 达不到。

十一、性能优势是真的,但有条件

DoH 常常比明文 UDP DNS 感觉更快,这一点让人意外。原因是连接复用:查询搭上了浏览器早已建立的、通往同一家解析器的 HTTPS 连接,既不额外往返,也没有冷启动惩罚。DoT 同理,前提是客户端保持 TLS 会话。而在冷启动、一条连接都没有的时候,加密 DNS 反而要先握手才能回答问题。

十二、那到底该怎么选

  • 按政策选解析器,别按跑分选。想清楚你更愿意把查询交给运营商、交给大厂,还是交给自己搭的一台——这是三种不同的取舍,最快的不等于最合适的。
  • 优先选有公开政策、有第三方审计、管辖地清楚的解析器。「零日志」是一个声明,去找那份验证过这个声明的审计报告。
  • 在自己能控制的网络上,用自建 DoT 解析器作为上游。过滤和内网名字都保留,同时到上游这一段仍然是加密的。
  • 留一条回退路径。只允许通过本地解析器查 DNS 的网络不是设计缺陷,它通常是认证门户或一条策略。隐私上失败即关闭,连通性上失败则放行。

ipbox.one 的 DNS 工具走 DNS-over-HTTPS 查询记录,首页则会告诉你实际应答查询的解析器是谁、它的归属地是否与你的出口一致。前者让你看到 DNSSEC 的签名是否在正常返回,后者让你看到加密 DNS 把你的查询交给了谁。

推荐阅读