加密 DNS
第 9 章 § 9.3 学了怎么用 nslookup 查域名，§ 9.6 的抓包实验里你可能已经隐约看到一件不对劲的事：你查的每一个域名，在网上是"喊"出来的——不加密、不密封、路过就能听见。HTTPS 普及后，网页内容穿上了盔甲（§ 8 章），可每次访问前的"问路"环节依然是明文：你还没进门，先在门口大喊"请问某某网站怎么走"——全走廊都听见了。这一节讲的就是给"问路"这件事本身加密：DoH、DoT、DoQ 三个缩写，本质是同一个问题的三种答案——怎么让"你去哪里"这件事，从公共广播变成私人耳语。但它远不只是一项隐私升级：围绕"谁有权看到你去哪里"，浏览器、运营商、监管者之间爆发了一场持续至今的暗战——这一节既讲技术，也讲技术背后那场没有硝烟的权力洗牌。
老式图书馆有个问询台，规矩很朴素：想找什么书，大声报书名，管理员大声回答"三楼东侧第七排"。高效、透明、所有人受益。
直到某天你注意到：问询台旁边常年坐着一位"闲人"，拿着小本子把每个人的提问都记下来——他记的本子越来越厚：你周一问过"跳槽攻略"，周二问过"失眠治疗"，周三问过"离婚财产分割"……他未必知道你是谁，但你的兴趣、烦恼、计划，全在那本子里排着队。
你要求图书馆改造：以后问询改用传纸条，管理员看完口头答复你，闲人一个字也看不到。馆长犯了难——传纸条当然能保护读者，可"大声报书名"支撑着整套老系统：馆员靠听提问来提前备书（缓存加速）、社区家长靠登记来拦"少儿不宜"（内容过滤）、警察办案靠调记录（合法监管）……保护读者和维持旧秩序，头一回正面相撞。
这座图书馆就是 DNS：问询台是域名解析（§ 9.3 的"查号台"），拿小本子的闲人是链路上的旁听者，传纸条就是本节的三种加密方案（DoT/DoH/DoQ），而馆长的两难——正是当下互联网治理的真实写照。
先把这一节的术语翻译成人话
本节缩写扎堆，但拆开都很好懂，先过表：
| 术语 | 翻译成人话 | 生活原型 |
|---|---|---|
| 明文 DNS | 喊出来的问路，路过全能听见 | 大嗓门问询台 |
| DoT | DNS over TLS——走专用加密信道的问路 | 问询台的加密专线 |
| DoH | DNS over HTTPS——伪装成普通网页流量的问路 | 把纸条夹在普通信件里 |
| DoQ | DNS over QUIC——走 QUIC 新高速路的问路 | 纸条改走新传送带 |
| HttpDNS | 国内 App 常用的 HTTP 接口查询方案 | 问询台开的另一个窗口 |
| SNI | HTTPS 握手时明文报出的目标域名 | 进门前的自报家门 |
| ECH | 把 SNI 也加密的新扩展 | 自报家门改用暗号 |
| 存根解析器 | 你设备上自带的"传话小弟"，只负责把问题递出去 | 办公室跑腿的实习生 |
| 递归解析器 | 替你跑腿查号的那个服务器 | 问询台管理员本人 |
| 迭代查询 | 逐级打听：先问根，再问顶级域，最后问权威 | 先问总台，再问楼层，最后问书架管理员 |
| DNSSEC | 给应答盖"防伪签名"，防篡改但不防偷看 | 银行支票上的防伪码 |
| TTL | 答案的保质期，过期就得重问 | 超市酸奶的保质期标签 |
| 旁听者 | 链路上能看到你流量的人 | 记小本子的闲人 |
复习与审视：DNS 裸奔了四十年
先把老朋友请回来。DNS（1983 年设计）是互联网的"名字转地址"系统：你敲 www.example.com，浏览器先去问 DNS"这个名字对应的门牌是多少"，拿到地址才能发起连接（§ 9.3 拆过它层层打听的全流程）。问题出在这套问答的传输方式：查询和应答走的是明文 UDP（或 TCP），端口 53——没有任何加密。这个设计在 1983 年无可指摘：那年头的互联网是几十个研究机构的小圈子，谈隐私如同在自家客厅谈窃听。可四十年过去，这套"明信片式"的问路系统原样服役到了人手一部手机、人人都靠它导航的时代。
裸奔的具体姿势，§ 9.6 的抓包实验给你留过实锤：Wireshark 里过滤 dns，你访问网站的每一个域名、时间、频率，白纸黑字全在——这不是漏洞，是协议的默认行为。更要命的是位置：DNS 查询发生在 HTTPS 连接之前，等于你给保险箱上了锁（TLS），却在开锁前把要去的房间号先广播了一遍。§ 8 章讲过 HTTPS 保护的是"信的内容"，而 DNS 明文泄露的是"信封上的收件人"——内容加密、信封裸奔，正是这二十年互联网隐私图景的写真题。
一条查询的旅程：五个旁听席
要看清风险到底铺在哪些路段，得把 § 9.3 讲过的查询旅程再走一遍——这次不关心"答案怎么拿到"，只关心"谁在路上能听见"。你在浏览器敲下一个域名后，问题从你设备上的存根解析器出发，交给运营商（或系统配置）的递归解析器；它如果缓存里没有现成答案，就开始逐级打听：先问根服务器"com 归谁管"，再问 .com 顶级域服务器"example.com 归谁管"，最后问权威服务器"www.example.com 的门牌是多少"。打个比方，这就是一封信从你家门口出发，途经小区收发室、片区邮政所、市局分拣中心，才送达目的地——每一站都是一间敞着门的办公室，信封内容人人可读。
把这条旅程上的旁听席数一数：第一席，你自己的 WiFi 或网线——咖啡馆的路由器、公司楼的出口、家里的智能设备，全部听得见；第二席，你的运营商——所有明文查询的第一站就是它的递归解析器，它甚至不用"偷听"，记录本来就经它手；第三席，骨干网上的 transit 运营商——查询跨网跨国的中转路上，一路明文过境；第四席，被查的那一边——根、顶级域、权威服务器同样能看到"谁在问什么"；第五席，任何能在其中任一路段做手脚的中间人——不听了，直接改答案（§ 8.6 的劫持与污染，稍后单说）。说白了，明文 DNS 时代你的"问路"行为暴露面是全链路敞开的，而绝大多数人对此一无所知，就像在开放办公区打了十年"免提电话"，从没想过隔壁工位听得一清二楚。
五个旁听席里，最容易被忽视、也最值得单独点名的是第二席。很多人以为"运营商只管收网费"，其实明文时代运营商的递归解析器天然持有一份用户的完整域名清单——什么时候睡、什么时候醒、装了什么 App、几点开始摸鱼，全在查询时间线里排着队。2015 年美国一份学术研究抽取了国内数家宽带运营商的 DNS 应答，发现部分 ISP 的返回结果被指向了广告伙伴的 IP；2017 年美国国会撤销了对 ISP 的上网隐私规则后，"运营商能合法利用你的浏览记录"从理论风险变成了现实预期——正是这两件事，把"加密 DNS"从学术论文里的一行字，推成了浏览器厂商的紧急议程。换句话说，DoH 的爆发不是技术 idealism 的胜利，更像一场被商业现实逼出来的自卫。
明文查询泄露的，是一本你的行为自传
"看到域名而已，有什么大不了？"——这是本节第一个要拆掉的轻视。单条查询确实无害（"某人此刻查了个购物网站"），但DNS 查询记录的价值在于聚合：它是一个人数字生活的完整目录。推演一遍画像过程：设备一联网就冒出来的一串域名，暴露你的手机型号和系统版本；通勤时间规律出现的导航类域名，暴露你的上下班时间和大概方位；深夜反复出现的域名，暴露你的失眠和搜索的病症；你查过机票比价、随后是酒店、再是翻译——一次完整的旅行计划跃然纸上。哪怕每条记录都不知道你是谁，只要它们来自同一个出口（同一个网络的同一批设备），这本"兴趣自传"就足够精准。
而这个画像的获取门槛低得吓人：不需要攻破任何服务器，只需要坐在你流量的必经之路上。咖啡馆的免费 WiFi、办公楼的出口路由、运营商的接入网——都是天然"旁听席"。本质上就是公交车上大声打电话：你以为在跟一个人说话，其实整车人都在拼凑你的行程。明文 DNS 的世界里，互联网的"全体乘客"拼你的画像，拼了四十年。
再往深一层看，这本"自传"的杀伤力恰恰在于它比浏览历史更全。不妨这样想：浏览器历史只记你"主动访问"的页，而 DNS 记录的是设备的全部网络活动——你没点开的推送预加载、App 后台的静默心跳、智能音箱每隔几秒的联网请求、手表的健康数据上传，全都先过一道明文问路。你早上问运动手环"今天心率多少"，手环回话前要先喊一嗓子某厂商的域名；你半夜失眠刷手机，凌晨三点的查询序列比你的日记更诚实。医院讲究"病历隐私"，可你搜索病症的域名先在公共信道上喊了一遍；银行讲究"账户保密"，可你查网银的域名同样喊了一遍——墙内守得再严，门口的喊话早把底牌掀了。
威胁分两路：偷听的与篡改的
讲到这儿必须踩一脚刹车，把概念分清楚——因为这是全网科普最容易混淆的一对概念：针对 DNS 的威胁其实分两路，一路是"偷听"（被动），一路是"篡改"（主动），而防它们的是两套完全不同的技术。偷听就是前面讲的旁听记账：不改你的流量，只是看；篡改则是 § 8.6 讲过的劫持与污染：半路把答案换掉，把你引去假门牌。打个比方：偷听是快递员偷看你包裹里买了什么药（隐私问题），篡改是快递员掉包了你的包裹（真伪问题）——一个伤的是"秘密"，一个伤的是"信任"，药方自然也不一样。
防篡改的老方案叫 DNSSEC（DNS 安全扩展）：让每一份权威应答都带上密码学签名，你的解析器验一眼签名，就知道答案是不是"正主"发的、路上有没有被掉包——就像银行支票上的防伪码，收票人自己就能验真伪，不需要跑回银行。听着很美？但 DNSSEC 有个致命的性格特点：它只签名，不加密。支票有了防伪码，可支票内容依然摊在桌面上任人阅读——DNSSEC 保证了"答案是真的"，却让"你问了什么"继续全链路广播。打个不恰当的比方，它给信封换了防拆封条，但信封依然是透明的。这就是为什么 DNSSEC 从 2005 年开始推广、将近二十年下来根和顶级域基本签完，隐私问题却原地踏步——它压根就没打算解决这个问题。
所以本节的三位主角（DoT/DoH/DoQ）和 DNSSEC 之间，不是竞争关系，而是各修各的车道：加密传输管"别让人听见"，DNSSEC 管"别让人掉包"，两把锁锁两扇不同的门，理论上可以同时上（签名的内容装进加密的信道里发）。简单说：DoH 解决的是 DNSSEC 从未涉足的另一半问题。理解了这层分工，你再看到"有了 DNSSEC 为什么还要 DoH"之类的争论，就能一眼看穿：那是在拿防伪码的说明书去质疑保密信封——两份说明书写的是两件事。顺带一提，现实部署里两者常被分开看待还有个工程原因：DNSSEC 的签名验证给每次查询加了计算开销，对分秒必争的公共解析器是个负担，这让不少大厂在"要不要默认开验签"上格外谨慎——技术上的"正确答案"到了工程世界里，永远要跟成本谈判，这句话你在 § 10.2 的 CPU 税里已经听过一遍了。
三条加密路线：DoT、DoH、DoQ 分头出圈
解决方案的方向只有一个——把"问路"装进加密信道。但怎么装、装进哪条信道，业界交出了三份答卷，一份比一份巧：
- DoT（2016 年定稿）最直白的方案：给 DNS 专门开一条 TLS 加密专线（端口 853），问询内容全程加密。相当于图书馆装了部保密电话——干净利落，但专线就是专线，"闲人"虽然听不见内容，却看得见你总在拨那个保密电话的号码。特征明显，容易被识别乃至拦截。
- DoH（2018 年定稿）最会藏的方案：把 DNS 查询伪装成普通的 HTTPS 网页流量（端口 443，跟所有网页走同一条道）。旁听者只看得见你在跟某台服务器"正常上网"，根本分不清哪是网页、哪是问路——混入人海，藏于无形。
- DoQ（2022 年定稿）最新的方案：让 DNS 查询走 QUIC（§ 10.2 的新地基）——继承 0-RTT 的快、抗丢包的稳，一次查询少一个来回，弱网下问路不再卡壳。相当于纸条改走 § 10.2 那套新传送带。
三份答卷的高下之心，藏在一个熟悉的模式里：DoH 是"借壳"思想的又一次胜利。§ 10.2 QUIC 借 UDP 的壳绕开协议僵化，§ 10.3 隧道借 IPv4 的信封寄 IPv6 的信，DoH 借 HTTPS 的外衣藏 DNS 的查询——三次借壳，同一个心法：当"特立独行"会被围剿，就打扮成最普通的样子混过去。专用端口（DoT 的 853）等于自报"我是加密 DNS"，网络管理员想拦一眼认出；而 DoH 的 443 端口上跑着全世界一半的流量，拦它等于拦整个互联网——藏于九百万流之中，这是战术上的完胜。
再补一笔性能账，免得你以为加密只有"隐私"一个卖点。老式明文查询看着轻（一句 UDP 就完事），但它有个隐性浪费：每次查询都是孤立的一锤子买卖，今天问了明天还得重新问。DoH 把查询挂进一条长活的 HTTPS 连接后，画风变了——第一次查询要付握手成本，可连接一旦建立，后续查询在这条"老线"上随问随答，连 TLS 握手都省了；DoQ 更进一步，把 § 10.2 的 0-RTT 也搬了过来，弱网和跨境场景下，重连开销几乎清零。想象一下餐厅点菜：老方案是每点一道菜就把服务员叫来重新握手寒暄一次，新方案是服务员就站在桌边，连报三道菜一口气下完——加密看似多穿了层盔甲，跑起来反而更顺，这在本章已经是第二次出现（第一次是 QUIC 的握手合并），快和稳常常是同一枚硬币的两面。当然账要算全：如果解析器远在另一个大洲，一来一回的物理延迟（§ 10.2 的 RTT 账本）照样跑不掉——加密提速的前提，是解析器本身够近够快，这笔账后面"反方账本"还会翻回来算。
浏览器入场：一次改变格局的默认设置
技术标准定稿只是拿到了"武器"，真正改变普通人网络生活的是浏览器的默认设置——这一步走得波澜起伏。2018 年起，Firefox 率先把 DoH 做成默认开启（部分地区可自动升级到加密查询），随后主流浏览器、操作系统陆续跟进：安卓系统设置里的"私人 DNS"、新版 Windows 内置的 DoH 支持、各浏览器的"安全 DNS"开关——加密问路从极客的可选项，逐步变成了亿万人无感参与的默认项。你此刻的浏览器很可能已经在用加密 DNS 了，证据藏在设置页里（见本节动手清单）。
但"默认加密"的每一步都踩在争议上。反对方的主力之一恰恰是运营商——他们的账本很现实：明文 DNS 时代，运营商的本地解析器承担着"片区缓存加速"（§ 9.3 讲过就近答话的延迟优势）和"合规过滤"的角色；DoH 一开，用户的查询绕过运营商、直奔第三方公共解析器，缓存优势旁落、过滤机制落空、还多了一个"第三方比我更懂我的用户"的心病。家长控制派同样焦虑：家里路由器上"拦不良网站"的功能，多数正拦在明文 DNS 这一层——加密之后，这层闸门失效，管孩子的家长和管理机房的管理员，罕见地站在了同一条战壕。隐私与管控的冲突，在 DNS 这个"小协议"上完成了全量预演。这也是为什么各家的策略都是"渐进 + 可退出"：先自动升级、保留关闭开关、尊重系统配置——工程上很简单的一步，治理上走了整整好几年。
这场争论的白热化程度，2019 年有过教科书级的一幕：英国的几家大型宽带运营商（BT、Sky、Virgin Media 等）联名致信 Mozilla，明确反对 Firefox 在英国默认启用 DoH——理由正是上面那本账：绕开运营商解析器，等于绕开英国的法定内容过滤体系（他们的家庭宽带默认拦不良内容，靠的就是 DNS 这一层）。同年，美国也有参议员公开致信多家浏览器厂商，质询"默认加密 DNS"对执法与儿童保护的冲击。有意思的是各方的应对姿势：Mozilla 没有硬推全球一刀切，而是搞出一份"可信解析器"名单，一个国家一个国家地谈——跟该国监管达成共识才在该地区默认开启；苹果则在 iOS 上走了另一条路：不跟运营商对着抢，而是把"iCloud 私人中继"做成用户主动付费订阅的可选项。同一个技术目标，三条治理路线（硬推、逐国谈判、用户自选），这本身就是一堂活的"技术政治学"课。说白了，代码三行就能改的默认值，真正的部署难度从来不在代码里。
解析器战争：新权力中心的形成
加密 DNS 的普及还制造了一个当初没人预料的副产物：递归解析器这个跑腿角色，从各片区的"小卖部"变成了全球连锁的"中央商场"。时间线很说明问题：2009 年 Google 推出 8.8.8.8 公共解析器，2018 年 Cloudflare 推出 1.1.1.1 并承诺不永久留存用户 IP、不把查询记录卖给广告商——两家都以"快"和"尊重隐私"为招牌，短短几年间，全球相当大比例的 DNS 查询汇聚到屈指可数的几个公共解析器手里。DoH 又给这场集中化踩了油门：浏览器默认开启 DoH 时总要指向某个解析器，而默认选项只可能给大厂——就像小区门口的菜市场一个接一个关张，所有人都进了同一家连锁超市：货架更整齐、灯更亮、价签更透明，但所有家庭的菜篮子清单，从此记在同一家公司的账本上。
这就是"代价四"要展开的核心矛盾：隐私没有被消灭，只是被搬家了。明文时代你的域名清单散落在链路上的五个旁听席，人人能看但人人只看得到一段；加密时代清单整整齐齐收进一家解析器的日志，链路清净了，账本却更全了。听起来吓人？把两面都摆出来才公平：支持方的论据是硬的——大厂受制于公众监督、隐私承诺写在明面上、有独立审计，比"谁路过谁都能看"的旧世界确实强；反对方的论据也是硬的——承诺可以被修改、日志政策说不准哪天随并购易主、而且无论承诺怎么写，"全部鸡蛋在一个篮子"的结构性风险不会消失。说白了，这是一道没有标准答案的权衡题：分散但裸奔，还是集中但上锁。§ 8 章零信任那一节的结论在这里原样适用：问题从来不是"信不信"，而是"凭什么信、谁能核查、错了怎么办"。
这场"战争"还有一个企业网络视角的战场。公司内网靠的是"内网域名只在内部 DNS 里有答案"（§ 9.3 讲过的分流解析），员工浏览器一旦擅自开启 DoH 指向外部公共解析器，内网系统立刻查无此人——本节末尾测验题考的就是这个坑。于是 IT 部门和浏览器厂商玩起了猫鼠游戏：浏览器检测到网络环境存在"企业管理解析器"信号时自动降级回系统 DNS（正好呼应上面"渐进 + 可退出"的路线）。你看，连"要不要加密"这件事，在不同语境下的正确答案都不一样——家用场景默认加密是福利，企业场景强行加密是事故，这也是全书反复出现的那条元规律：技术方案永远长在具体场景里，脱离场景谈好坏都是空转。
最后一层裸奔：ECH 给 SNI 也穿上盔甲
DoH 加密了"问路"，但条条大路通向同一个终点：HTTPS 连接建立时，还有一次明文"自报家门"。这就要说到 TLS 握手的一个历史遗留：SNI（服务器名称指示）——因为一台服务器（一个 IP）上可能托管着几十个网站（§ 10.3 讲过地址紧张，共享服务器是常态），你的浏览器必须在握手的第一句话里明文报出"我要找这台服务器上的哪个域名"，服务器才知道该出示哪张证书（§ 8.2）。结果：DNS 加密了、网页内容加密了，可握手这一嗓子"SNI"，把你要访问的域名又广播了一遍——旁听者根本不用看 DNS，蹲在 HTTPS 门口就能记账。
补上这最后一块拼图的方案叫 ECH（加密客户端问候）：让浏览器把"要找哪个域名"这句自报家门也用公钥加密，只在服务器端拆开——旁听者最后的一扇窗也被糊上。ECH 的部署与 DoH 是天作之合：ECH 需要知道目标站点的加密参数，而这份参数恰恰通过（加密的）DNS 分发——两项技术合龙，"访问了哪个网站"这件事才算真正退出了公共广播。顺带说破一层窗户纸：ECH 至今仍在标准定稿前的最后打磨与逐步部署阶段，落地节奏各家公司不一——本节讲它，是让你看见"隐私拼图"的全貌和走向；至于你某次握手用没用上，工具箱自会告诉你（§ 9.6 抓包看 ClientHello 有没有加密段，是检测手段之一）。
中国实践：HttpDNS 的土洋结合
把视野拉回国内，还有一条极具本土特色的技术支线——HttpDNS。它的诞生动机很实际：国内网络环境里，明文 DNS 的"劫持/污染"问题（§ 8.6 讲过：应答被半路篡改）曾相当普遍——运营商插广告、区域网络改解析，受害的是 App 的连接速度和用户体验。以 App 的视角看，与其等网络环境变好，不如自救：干脆不走 53 端口了——把"查个域名"做成一个普通的 HTTP 接口调用，App 直接向服务提供商的接口发请求拿结果。查询走的是 HTTP(S)，中间设备要么看不懂（若走 HTTPS）、要么不好插手（流量与普通 API 无异），劫持的老套路瞬间失效。
HttpDNS 和 DoH 的关系耐人寻味：思路同源（都是"让 DNS 请求混进普通流量"），出身不同（一个是企业的工程自救，一个是 IETF 的正式标准），殊途同归（今天国内的头部 App 和主流云厂商，两套方案都在大规模使用）。它给普通读者的启示比技术细节更宝贵：标准是理想主义的蓝图，工程是现实主义的施工——当标准还没铺到你的战场，先用工程手段把问题解决了，再等标准来收编。中国互联网的很多"土办法"，走的都是这条先上车后补票的路。
反方账本：加密 DNS 的四笔代价
本节至此都在讲加密的好处，按本站铁律，必须把反方账本完整摊开——加密 DNS 不是免费的正义，它真实地付出了四笔代价：
- 代价一：可见性没了，排错难了§ 9.3 的整套排查法建立在"查询可见"上：抓包看问的谁、答的谁、应答长什么样。DoH 一开，你在 Wireshark 里只能看到一团加密流量——"域名到底解析成什么了"从公开信息变成了黑箱。排错工具被迫跟着升级（看浏览器日志、用专门工具直连测试），老一套的透明度一去不返。
- 代价二：本地缓存旁路，可能更慢运营商的本地解析器就架在你家网络附近，答话延迟以毫秒计；DoH 把查询发往另一个城市的公共解析器，延迟未必占优——虽然 DoH 客户端自己也有缓存兜底，但"加密一定更快"是不成立的，快慢取决于缓存命中率和解析器位置。
- 代价三：管控手段被迫重新设计家长控制、企业合规过滤、行业监管——过去搭在明文 DNS 这层"免费闸门"上的功能全部失效，必须迁移到端上（设备本身的过滤）或网关上（HTTPS 内容审查另说）。这不是技术退步，但确实是一次"旧秩序清零、新秩序重建"的昂贵搬迁。
- 代价四：信任的转移，不是消失最深刻的一笔：你只是把"能看到你全部行踪"的权力，从运营商移交给了公共解析器的运营方。查询日志集中到少数几家大厂手里，是更安全还是更危险？——这是本节留给你的开放思考题，§ 8 章零信任的教训在这里依然成立：信任要给谁，永远比"要不要信任"更重要。
这份账单的姿势你应当已经很熟悉了：它和 QUIC 的 CPU 税、IPv6 的三十年长跑一脉相承——每一次协议升级，本质都是一次"利益的再分配"：谁看得见、谁说了算、谁付成本。技术只是把这个问题从"没人好意思问"逼到了"必须摆上桌面"。
一张对照表：问路系统的四十年
| 维度 | 明文 DNS（1983） | DoT（2016） | DoH（2018） | DoQ（2022） |
|---|---|---|---|---|
| 传输方式 | 明文 UDP/TCP | TLS 加密专线 | HTTPS 混装 | QUIC 加密 |
| 端口 | 53 | 853 | 443（人海隐身） | 443（UDP） |
| 旁听者看到 | 全部域名+频率 | 加密流量（特征可辨） | 与普通网页无异 | 与 QUIC 流量无异 |
| 被拦截难度 | 轻而易举 | 较易（端口醒目） | 很难（误伤全网） | 难 |
| 速度优势 | 最简 | 多了 TLS 握手 | 可复用连接 | 0-RTT、抗丢包 |
| 典型用户 | 全体（默认） | 系统级配置 | 浏览器默认趋势 | 新一代客户端 |
读表提示：四个方案不是"四选一淘汰赛"，而是同一棵树上先后长出的四根枝——明文 DNS 仍是兜底默认，DoT 在系统层服役，DoH 在浏览器层燎原，DoQ 在新地基上接力。互联网从不删旧枝，只长新枝——这句话在本章已经是第三次应验了。
第一阶段（明文 DNS）：大嗓门问询，四十年如一日。管理员嗓门洪亮、答得飞快（本地缓存），闲人的小本子也越记越厚——直到某天读者们集体觉醒：这本自传不能白送。
第二阶段（DoT）：馆里装了保密专线。想密语的读者拿起专线电话——内容保密了，但闲人认得那部电话："又有人开始密语了"，想掐线虽费点劲，掐得动。管家长控、馆员备书的旧机制也跟着抓瞎：专线里说什么，谁都不知道。
第三阶段（DoH）：密语纸条混进普通信件。读者学聪明了——把问题写在信里，跟日常书信一个信封、一个邮筒，闲人拆无可拆、拦无可拦（拦信等于拦全城通信）。家长和馆长的旧闸门彻底落空，只好另想办法：要么在读者自己家里装滤网（端上控制），要么跟收信的新邮局谈规矩（解析器侧配合）。
第四阶段（ECH）：进门暗号也加密。剩下的最后一个破绽是进门时那句自报家门——如今改成对暗号，除了管理员谁也听不懂。到此，"谁在读什么书"这件事，终于只有读者自己和管理员知道。
支线（HttpDNS）：城东的写字楼嫌图书馆规矩多，干脆在自己大堂开了个传话窗口——楼里的公司问路不走图书馆，直接递条子给窗口，闲人连"你去没去图书馆"都看不到了。这条支线不是标准的一部分，却先于标准解决了实际问题——图书馆后来推出的密语服务（DoH），思路跟这个土窗口如出一辙。
而这场改造最深的暗线：四十年里"谁有权知道读者读什么"从未被讨论过——因为答案被默认成了"路过的所有人"。加密 DNS 没有发明新权力，它只是第一次把这个问题摆上台面，逼所有人重新签字。技术的每一次加密，都是一次权力的重新分配。
密语时代的排错：老工具的新盲区
§ 9.3 教的那套 DNS 排查法，在加密时代多了一层新陷阱，必须明说：nslookup 和 dig 测的是"系统配置的解析器"，走的是老 53 端口（明文）；而你的浏览器很可能正用自己另配的 DoH 解析器——两者压根不是同一条路。于是会出现一种以前不可能的怪事：命令行里 nslookup 显示解析正常，浏览器里页面就是打不开（或者反过来）；或者同一个域名，命令行和浏览器给出两个不同的 IP。第一次遇到的人多半怀疑人生，其实这就是"两套问路系统各自为政"的标准症状——你的电脑里同时住着一个走明文的传令兵和一个走密语的信使，你问传令兵的话，永远听不到信使那边的动静。
排查心法分三步：第一步，先确认设备上到底有几套解析器在跑——系统一套（ipconfig /all 或网络设置里看），浏览器一套（安全 DNS 设置里看），某些 App 还自带第三套（HttpDNS）；第二步，用"同一条路"去验证——怀疑浏览器打不开是 DNS 问题，就别拿 nslookup 测（它测的是另一条路），要么在浏览器地址栏访问测试页，要么用支持 DoH 的工具直连测试；第三步，抓包定乾坤——Wireshark 里同时盯着 53 端口和 443 端口：如果故障发生时 53 端口一片安静、443 上的加密查询也寥寥，问题多半不在 DNS，而在更深处（连接、证书、路由）。说白了，加密时代排错的总原则就一句：先搞清楚"这次失败的请求，走的是哪条问路"，再谈排查。
试着观察：nslookup 走的是系统明文解析器，它永远测不到浏览器的 DoH——这就是"工具盲区"的活教材。
动手清单：看看你在不在密语时代
- 浏览器设置里搜"安全 DNS"（Chrome/Edge：设置 → 隐私和安全 → 安全；Firefox：设置 → 隐私与安全 →最底部的 DNS over HTTPS）——看看你的开关状态和使用模式；
- 安卓手机：设置 → 网络 → 私人 DNS——填入支持 DoT 的解析器域名，整机所有 App 的查询都加密（不止浏览器）；
- 验证加密生效：开 Wireshark 过滤
dns，再浏览几个新网站——如果 DNS 查询寥寥无几而 udp/tcp 443 流量汹涌，说明大部分问路已转密语；对照 § 9.6 的明文时代实验，你会看到两个世界； - 命令行对照：
nslookup走的是老 53 端口（明文），所以它能测出"系统 DNS"却测不到"浏览器实际用的 DoH"——想想为什么这俩可能给出不同答案（提示：§ 9.3 的排查法在加密时代要加一层"浏览器用的哪套解析器"）； - 抓一次 ClientHello（§ 9.6 的功课）看看 SNI 字段：明文可见的域名就是 ECH 要糊上的那扇窗。
常见误区
- 误区一："开了 HTTPS，我的访问就保密了"HTTPS 只加密信的内容；去哪个网站（DNS 查询）和握手时的 SNI，长期是明文——旁听者虽看不见你读了什么，看得一清二楚你在读谁。DoH + ECH 合龙后，"读谁"才真正进入密语时代。
- 误区二："DoH 是完全无法发现的隐身术"DoH 藏的是内容，不是行为：网络管理员依然看得到你与某台解析器之间有加密流量，也能封掉知名公共解析器的地址段——只是"误伤普通网页"的代价让封堵投鼠忌器。藏于九百万流，不等于绝对隐形。
- 误区三："加密 DNS 能防住 § 8.6 讲的 DNS 劫持污染，所以一切网络问题都解决了"它确实掐断了"篡改 53 端口应答"这条老劫持路，但网络故障的原因千千万（§ 9 章整整一章）：路由不通、证书错误、服务器宕机……加密问路防的是"指错路的人"，防不了"路本身断了"。
- 误区四："用了加密 DNS，网速会变快"没有必然关系：可能更快（好的公共解析器+连接复用），也可能更慢（绕过了运营商的本地缓存）。解析速度取决于缓存命中率和解析器远近——加密改变的是隐私属性，不是速度属性。
- 误区五："这是纯技术问题"恰恰相反，它是本节最不"纯技术"的部分：家长控制、企业过滤、运营商角色、监管边界全部被牵动——技术方案三行代码就能切换，治理共识走了十年没走完。看懂这一点，你看一切"技术争议"的眼光都会变。
- 误区六："开了加密 DNS，我就匿名上网了"高估了它的管辖范围：DoH 加密的只是"问路"这一段，你连上网站后，网站照样看到你的 IP、你的浏览器指纹、你的登录状态——相当于问路改成了耳语，但进店之后店员依然认得你的脸。加密 DNS 是隐私拼图的一块，不是匿名斗篷；想接近"匿名"，那是另一套工具（代理/VPN，§ 8.5）的活儿，两者解决的问题不同、也互不替代。
- 误区七："DoH 和 DNSSEC 是竞争关系，二选一"这是把两把不同的锁当成了对手：DNSSEC 防"答案被掉包"（验真），加密传输防"问题被偷听"（保密）——一个管真伪，一个管隐私，理论上可以同时启用。混淆它们的争论，多半是在拿防伪码的说明书去质疑保密信封。
带走三句话。第一，裸奔的清单比想象长：内容早有 HTTPS 加密，可"问路"（DNS）和"自报家门"（SNI）明文了四十年——你的兴趣自传一直在被链路上的旁听者免费阅读，DoH/DoT/DoQ 与 ECH 正在把这两层也逐一糊严。第二，借壳是三代人共同的兵法：QUIC 借 UDP、隧道借 IPv4、DoH 借 HTTPS——新协议想活下来，先学会打扮成老协议的样子。第三，加密即权力再分配：从运营商到浏览器厂商，从家长控制到企业过滤，每一次"多加密一层"，都是"谁有权看见"的一次重新签字——技术只负责把问题摆上桌，答案要所有人一起写。
本节讲的是"别让旁人听见你要去哪"。可无论问路多保密，真正决定你多久能到的，是另一件事：路上的车流量怎么调度。三十年来，所有车都遵循一条古老的堵车法则——"看到丢包才减速"，结果高延迟的深海光缆上，明明路很空、车却不敢跑快。Google 的 BBR 换了一套思路：不猜、去测，把路真正的容量开出来。下一节，也是网络篇的最后一节：BBR 拥塞控制——给互联网的油门装上传感器。