DoH/DoT 与 DNS 安全
基于 HTTP 现代标准 · 核于 2026-06
速查
- 传统 DNS 的原罪：查询默认走明文 UDP（53 端口），像寄明信片——链路上任何人（运营商、网管、攻击者）都能看清你在访问哪个域名，即便目标站点是 HTTPS，那一次 DNS 查询仍暴露在外。
- 明文带来三类风险：窃听 / 监控（看你查了什么）、DNS 劫持 / 投毒（把你导向假站点）、运营商劫持插广告（篡改响应、注入跳转）。
- DoT（DNS over TLS）：在 UDP 之上套一层 TLS 加密，走专用 853 端口；既加密又防在途篡改，但因端口专一，网管「能看见有 DoT 流量在跑」（看不到内容）。
- DoH（DNS over HTTPS）：DNS 查询藏进 HTTPS（HTTP/2）流量，走 443 端口，与普通网页流量混在一起、难以识别与封锁（RFC 8484）。
- DoT vs DoH 的关键区别：端口（853 / 443）、可见性（可识别 / 被伪装）、立场（利于网管管控 / 利于用户隐私）——技术上都加密，差在「藏得多深」。
- 浏览器支持：Firefox 自 2020 年起在美区默认开启 DoH（解析器为 Cloudflare 或 NextDNS），Chrome/Edge 提供「安全 DNS」开关（默认多为「随系统」，可手选 DoH 提供商）。
- DNSSEC 是验真不是加密：用数字签名验证 DNS 响应未被篡改、确实来自权威源，沿「根→TLD→权威」建立信任链；它不加密查询内容，解决的是「真实性 / 完整性」。
- 一句话分工：DoT/DoH 管「别人看不到、改不了」（加密 + 防途中篡改），DNSSEC 管「答案是真的」（来源真实性）——两者正交，可叠加使用。
- 隐私权衡：DoH/DoT 挡住了链路上的旁观者，但你选用的递归解析器本身仍然知道你查了什么——隐私从「运营商」转移到了「解析器提供商」，选谁要看其隐私政策。
- 工程取向：终端用户重隐私多用 DoH；企业 / 校园网为可管控、可拦恶意域名常偏好 DoT 或自建解析器。
传统 DNS 为什么不安全
DNS 是互联网的「电话簿」，把域名翻译成 IP。但它诞生时根本没考虑安全：查询和响应默认以明文经 UDP 53 端口收发，没有加密、没有来源验证。这就像把要去哪儿写在明信片背面寄出——任何经手的人都能瞥见。
由此衍生出一组现实威胁：
- 窃听与监控：链路上的运营商、公共 Wi-Fi 管理者、在途攻击者都能逐条读到你的域名查询，从而画出你的浏览画像。即使网站用了 HTTPS（隐藏了页面内容），「你想访问 bank.com」这件事本身仍通过 DNS 泄露。
- DNS 劫持（hijacking）：攻击者通过恶意软件或非法篡改，把查询导向另一台被控的域名服务器，返回假 IP，把你带到钓鱼 / 挂马站点。
- DNS 缓存投毒 / 污染（cache poisoning / spoofing）：把伪造的解析记录塞进解析器缓存，使其在缓存有效期内对某域名持续返回错误 IP，受影响的是命中该缓存的所有用户。
- 运营商劫持插广告：部分网络中间方篡改明文响应，把你导向带广告的中转页，或在解析层做重定向——明文 + 无验证让这一切几乎零成本。
把常见的 DNS 攻击按「攻击点」归一下类，能更清楚地看出加密与验真各自管哪一块：
| 攻击类型 | 攻击点 | 效果 | 被谁缓解 |
|---|---|---|---|
| 缓存投毒 / 欺骗（cache poisoning） | 递归解析器缓存 | 缓存期内对某域名持续返回假 IP | DNSSEC（验真） |
| DNS 劫持（hijacking） | 篡改权威记录 / 改解析器指向 | 查询被导向被控服务器 | DNSSEC + 加固服务器 |
| 在途篡改 / 窃听（on-path） | 传输链路 | 读取或改写途中查询 | DoT/DoH（加密） |
| 运营商劫持插广告 | 链路 / 解析层 | 注入广告、重定向 | DoT/DoH（加密） |
| DNS 隧道（tunneling） | 借 DNS 夹带数据 | 绕过防火墙渗出 / 投放数据 | 流量监测、DNS 防火墙 |
明文 DNS 的两个独立缺陷
一是没加密（谁都能看、能改途中流量），二是没验真（拿不准答案是否来自真正的权威源）。后文的 DoT/DoH 主治前者，DNSSEC 主治后者——别把它们混为一谈。
缓存与 TTL 如何影响投毒的「波及时长」属上一环节，详见 DNS 缓存与 TTL，本页不展开。
DoT 与 DoH：给 DNS 查询「套上信封」
DoT 与 DoH 是两套独立标准，目标一致：加密明文 DNS 流量，让运营商、广告商、攻击者都无法解读，并顺带防止途中被伪造篡改。沿用明信片的比喻——它们给每张明信片都套上了信封。
- DoT（DNS over TLS）：在承载 DNS 的 UDP 之上叠加 TLS（HTTPS 站点用的同一套加密协议），走专用的 853 端口。查询被加密，且能抵御在途攻击者的伪造与篡改。
- DoH（DNS over HTTPS）：DNS 查询与响应不再直接走 UDP，而是封装进 HTTP / HTTP/2 报文，经 443 端口收发（RFC 8484 把每对查询-响应映射为一次 HTTP 交换）。在网管视角里，DoH 流量看起来就和普通的网页 HTTPS 访问一模一样。
DoT vs DoH 对比
二者都加密，最核心的差异是用哪个端口、因而有多「显眼」：
| 维度 | DoT（DNS over TLS） | DoH（DNS over HTTPS） |
|---|---|---|
| 端口 | 853（专用） | 443（与所有 HTTPS 共用） |
| 承载 | TLS over UDP | HTTP / HTTP/2 over TLS |
| 可见性 | 网管能识别有 DoT 流量（看不到内容） | 混入普通 HTTPS，难以识别、难单独封锁 |
| 网络管控 | 友好——可监控 / 拦截 DNS 以挡恶意域名 | 困难——不阻断全部 HTTPS 就拦不住它 |
| 隐私倾向 | 稍弱（流量可被定位） | 更强（藏进大流量中） |
| 典型立场 | 企业 / 校园网偏好 | 终端用户隐私偏好 |
没有绝对的「更好」
网络安全视角 DoT 往往更受欢迎：网管能监控、拦截 DNS 查询，便于发现和阻断恶意流量。隐私视角 DoH 更优：查询藏进 HTTPS 大流量里，网管可见性更低、用户隐私更高。要拦掉 DoH，几乎得连同所有 HTTPS 一起拦——代价过大。
浏览器对 DoH 的支持
DoH 在浏览器侧落地最广：
- Firefox：自 2020 年 2 月起为美区用户默认启用 DoH，加密后的查询发往 Cloudflare 或 NextDNS；其他地区可在设置中手动开启。
- Chrome / Edge：提供「安全 DNS（Secure DNS）」开关，默认多为「随当前系统的解析器」，也可手动指定支持 DoH 的提供商（如 Cloudflare、Google）。
这意味着应用层（浏览器）可以绕过操作系统设定的解析器，自行走 DoH——这是它强隐私的来源，但也因此引发过「企业 / 家长管控被旁路」的争议。
DNSSEC：验真，而不是加密
DNSSEC（DNS Security Extensions） 是为 DNS 补上来源真实性的一组安全扩展。它的做法是数字签名：每一级 DNS 数据都被签名，解析器通过验证签名，确认这条记录确实出自真正的权威服务器、且未被篡改。
- 签名像本人在法律文件上的亲笔签名——独一无二、无法伪造，验证方一看便知真伪；任何途中改动都会让签名校验失败。
- 它建立逐级信任链：以
google.com查询为例，根服务器为 .COM 签发密钥，.COM 再为google.com的权威服务器签发密钥，层层背书直到根区。链条任一环被破坏，请求即暴露于在途攻击。 - 根区本身由人工根区签名仪式（Root Zone Signing Ceremony） 公开审计地完成签名，作为整条信任链的锚点。
- DNSSEC 向后兼容：未部署的域名仍能正常解析（只是没有这层验证），它被设计为与 SSL/TLS 等共同构成整体安全策略。
- 部署现实：DNSSEC 需域名持有者在权威侧逐级开启、并把 DS 记录登记到上级，配置门槛与运维成本较高，因此全网覆盖率长期偏低；它验证的是「解析器拿到的答案为真」，而非「你到解析器这一段被加密」——后者仍要交给 DoT/DoH。
一定要写准：DNSSEC ≠ 加密
DNSSEC 不加密任何东西——查询内容依旧是明文，旁观者照样能看到你查了什么。它只保证「答案没被掉包」。要「别人看不见」，得靠 DoT/DoH。两者解决的是完全不同的问题：
- DNSSEC → 真实性 / 完整性（answer is authentic）
- DoT/DoH → 机密性 / 隐私（query is private）
理想状态是二者叠加：用 DoH/DoT 加密通道，再用 DNSSEC 验证答案真伪。Cloudflare 的 1.1.1.1 即同时支持 DoT、DoH 与 DNSSEC。
隐私权衡：加密之后，谁还看得见
加密 DNS 不是「隐私银弹」，有一个常被忽略的边界：
- 挡住了链路旁观者：开启 DoT/DoH 后，运营商、公共 Wi-Fi、在途攻击者无法再读取或篡改你的 DNS 查询。
- 解析器仍知道你查什么：你把全部查询都发给了所选的递归解析器（Cloudflare、Google、NextDNS……），它天然看得到你访问的每一个域名。隐私因此从「运营商」转移到了「解析器提供商」——并非消失。
- 因而选解析器 = 选信任对象：要看其隐私政策（是否记录、是否售卖查询数据、日志留存多久）。一个「不加密但不记录」的本地解析器，未必比「加密但记录并变现」的远端解析器更差。
- 加密 DNS 不等于完全匿名：即便 DNS 查询被加密，后续建立 TLS 连接时若未启用 ECH（Encrypted Client Hello），握手中的 SNI（目标域名）仍可能明文暴露给链路旁观者——也就是说，「你访问了哪个站点」未必只靠 DNS 一条途径泄露。SNI / ECH 的细节属 HTTPS 范畴，此处只点到为止。
给前端 / 个人的务实建议
- 个人重隐私：开启浏览器 DoH 或系统级加密 DNS，并挑一家隐私政策可信、支持 DNSSEC 的解析器。
- 企业 / 校园网：常更倾向 DoT 或自建递归解析器，以便在加密的同时仍能拦截恶意域名、满足合规与管控。
- 记住底线：加密 DNS 解决「中间链路偷窥」，不解决「你信任的解析器记录你」。
小结
传统 DNS 因明文 UDP + 无来源验证而天然脆弱，招致窃听监控、DNS 劫持、缓存投毒与运营商插广告。DoT（853 端口，TLS over UDP） 与 DoH（443 端口，藏进 HTTPS、更难识别封锁） 给查询「套上信封」，二者都加密、都防途中篡改，差别在端口与可见性——DoT 利于网管管控、DoH 利于用户隐私，浏览器侧以 Firefox 默认启用、Chrome/Edge「安全 DNS」开关为代表落地。而 DNSSEC 是验真不是加密：靠逐级数字签名保证答案未被掉包，与 DoT/DoH 正交、可叠加。最后别忘隐私的边界——加密只挡住链路旁观者，你选的解析器仍看得到你查什么。
至此 DNS 这一章收束完毕：从域名层级、解析流程、记录类型、缓存 TTL，到前端优化与本页的加密与安全。回看面向页面性能的那一环可移步上一页 前端 DNS 优化；术语、RFC 与工具速查见 参考。