DNS

你从来没背过任何一个网站的 IP 地址，但你天天都在访问它们。这中间有一位你从没打过招呼、却每天替你查上几百次号码的接线员——它叫 DNS。它慢一秒，你就觉得"网卡了"；它答错一次，你就打开了一个假网站。这一节把这本"互联网电话簿"从头翻到尾。

先把这一节的术语翻译成人话

DNS 这一节的名词密度不低，而且都长得挺唬人——"递归解析器"、"权威服务器"、"TTL"、"CNAME"。先把它们翻译成人话过一遍，后面读起来就顺了。这张表建议看完全篇再回来重读一次，你会发现每一行都对应了正文里的一个小节。

整节可以用一个画面串起来：你要找一个人，先翻自己抄的便签（缓存），没有就问前台（递归解析器），前台不知道就去问大厦总台（根），总台指路给楼层（TLD），楼层再指到具体办公室（权威服务器），最后办公室给出真号码。后面每一个小节，都是在把这条链子上的某一环拆开细看。

没有 DNS 的世界是什么样

要理解 DNS 为什么重要，最快的办法是想想假如它不存在。

互联网上真正能送数据的地址是 IP 地址（IP Address，网络上一台机器的门牌号，如 93.184.216.34）——四段数字，或者 IPv6 那种更长的十六进制串。路由器只认这个，它压根不认识 baidu.com 这几个字母。

所以没有 DNS 的话，你的生活会变成这样：想看视频，得先记住 119.3.70.188；想搜东西，得记住另外一串；朋友给你推荐网站，发过来的是一串数字。换成大白话：相当于把你手机通讯录全删了，从此打电话只能靠背号码。

而更糟的是第二层麻烦：那串数字还会变。网站换机房、换云服务商、扩容加机器、故障切换到备用节点——IP 地址随时可能换。要是大家都靠背数字上网，相当于你家小区门牌号每个月重排一次，所有亲戚朋友都得重新记一遍。

DNS 解决的正是这两件事，一句话概括就是：它在"人记得住的名字"和"机器能用的地址"之间加了一层可以随时改的对照表。名字对外保持不变，地址在背后爱怎么换怎么换。这一层"间接"带来的好处，远远超出"省得背数字"：

• 换机器不用通知任何人服务器搬到新机房，只需要改一条 DNS 记录，全世界访问的还是同一个名字。好比你换了手机号只需要在通讯录里改一处，别人点你的名字照样打得通。
• 一个名字可以指向很多台机器同一个域名可以配多条地址记录，请求被分摊到不同服务器上——这是最原始也最广泛使用的负载均衡手段。相当于一家餐厅公布一个总机号，接起来的可能是三个不同的服务员。
• 不同地方的人可以得到不同答案北京的用户和纽约的用户查同一个名字，可以拿到离自己最近的那台机器的地址。这是 CDN（内容分发网络）能生效的地基之一。
• 出故障能快速切换主服务器挂了，把记录改成备用机的地址，几分钟内流量就切过去了——前提是"保质期"设得够短，这个后面讲 TTL 时会细说。

DNS 的规范主体是 RFC 1034（概念与设施）和 RFC 1035（实现与规范），两份都是 1987 年 11 月发布的，作者是 Paul Mockapetris。这套设计四十年不倒，且规模从几百台机器长到几百亿台设备，中间核心结构几乎没动过——这在计算机领域相当罕见。后来的几十份 RFC 都是在往上加东西（加安全、加加密、加扩展），而不是推翻重来。

域名是一棵倒着长的树

DNS 的第一个设计精髓，藏在域名的写法里。

看这个域名：www.example.com。你习惯从左往右读，但 DNS 是从右往左理解它的。右边越靠外、范围越大；左边越靠里、越具体。

打个比方，这跟写地址的顺序一模一样。中文写地址是"北京市 → 海淀区 → 中关村大街 1 号 → 3 单元 → 502"，从大到小。域名只是把这个顺序反过来写，并且用点号隔开：502 . 3单元 . 中关村大街1号 . 海淀区 . 北京市。你要找那个 502，也得先确定是哪个市、哪个区——DNS 的查询顺序完全一样。

          www . example . com .
           │      │        │   │
           │      │        │   └── 根（root），写法是一个空的点
           │      │        │        平时省略不写，但它真实存在
           │      │        └────── 顶级域 TLD（.com）
           │      └─────────────── 二级域（example，通常是"某家公司"）
           └────────────────────── 主机名 / 三级域（www，具体某台服务器）

对照着看写地址：
          502 . 3单元 . 中关村大街1号 . 海淀区 . 北京市 . 中国
                                                          ↑
                                              这就是"根"的位置

★ 关键：域名末尾其实有一个点（www.example.com.）
  这个点代表"根"。浏览器帮你省略了，
  但在 DNS 的世界里，所有查询都从这个点开始往回走。

这棵树的层级不止三层。mail.corp.beijing.example.com 就是五层——完全合法，规范允许最多 127 层，每一层标签最长 63 个字符，整个域名总长不超过 255 字节（这些上限都写在 RFC 1035 里）。实际生活中很少超过五层，因为再深人就记不住了。

树形结构带来一个极其重要的好处：管理权可以逐层下放。相当于市政府不需要知道每一栋楼里每一户的门牌，它只需要知道"海淀区的事情由海淀区管"。具体到 DNS：

• 根只管一件事根服务器不知道 example.com 在哪，它只知道"所有 .com 的事情去问这批服务器"。就这一件事。
• .com 的服务器也只管一件事它不知道 www.example.com 的地址，它只知道"example.com 的事情去问那两台服务器"。
• example.com 自己的服务器才给最终答案它是这个域名的权威服务器——正主，它说是什么地址就是什么地址。

这种"每一层只知道下一层是谁"的设计，就是 DNS 能撑住全球规模的根本原因。换成大白话：没有任何一台机器保存着全世界所有域名的答案，甚至没有任何一台机器知道全世界有多少个域名。每一台只管自己那一小块，往下的事一律"这个你去问他"。

这里要区分一组容易混的概念：域（domain）是名字空间上的一块，区（zone）是"实际由某一组服务器负责应答的那一块"。一个域可以被切成多个区分别托管，也可以整个域就是一个区。打个比方：域好比"海淀区"这个行政概念，区好比"实际派出所的辖区划分"——通常一致，但可以再切分。

递归查询 vs 迭代查询：一字之差，角色完全不同

这一对概念是 DNS 里最常被讲错的地方，值得单独用一节掰清楚。它们的区别不在"查得快不快"，而在"谁来干跑腿这件事"。

递归查询（Recursive Query）——你发一个问题，要求对方把最终答案给你，中间过程你完全不管。RFC 1034 里描述的行为是：客户端在查询里置上"希望递归"的标志（也就是报文头里那个 RD 位，Recursion Desired），如果服务器愿意并且能提供递归服务，它就有义务把这件事办到底，最后只回给你一个结果。

迭代查询（Iterative Query）——你问一次，对方只给你它知道的那一点：要么是答案，要么是"我不知道，但你可以去问某某"。然后你自己拿着这条线索再去问下一家。

换成大白话：递归是"你办不办？办好了告诉我"；迭代是"我知道谁可能知道，你自己去问吧"。

【一次完整解析：www.example.com 的八步】

你的电脑                递归解析器           被问到的服务器
   │                        │
   │ ① 递归查询             │
   │  "www.example.com 的 A 记录是啥？"（RD=1）
   ├───────────────────────>│
   │                        │ ② 迭代查询 → 根服务器
   │                        ├──────────────> 根（.）
   │                        │<────────────── "去问 .com 的服务器，
   │                        │                 它们在 a.gtld-servers.net 等"
   │                        │
   │                        │ ③ 迭代查询 → .com 的 TLD 服务器
   │                        ├──────────────> .com
   │                        │<────────────── "去问 example.com 的服务器
   │                        │                 ns1.example.com"
   │                        │
   │                        │ ④ 迭代查询 → example.com 的权威服务器
   │                        ├──────────────> example.com 权威
   │                        │<────────────── "A 记录 = 93.184.216.34
   │                        │                 TTL = 3600"
   │                        │
   │ ⑤ 一个最终答案         │ ⑥ 顺手存进缓存（存 3600 秒）
   │<───────────────────────┤
   │ "93.184.216.34"        │

★ 你只发了 1 个包、收了 1 个包。
★ 递归解析器发了 3 个包、收了 3 个包，并且是它在跑腿。
★ 下一个人来问同一个名字，第 ②③④ 步全部跳过 ——
  这就是缓存的威力。

【补充：还有一种"转发"模式】
  家里的路由器通常既不递归也不权威，
  它只是把你的查询原样转给运营商的解析器
  （这叫 forwarder / 转发器）。
  所以链条实际常常是：
    你 → 路由器（转发） → 运营商解析器（真正递归）
        → 根 / TLD / 权威（迭代）

顺便解释一个必然会被问到的问题：递归解析器怎么知道根服务器在哪？这不能再靠 DNS 查——那就成了鸡生蛋。答案是：根服务器的地址是写死在软件里的一份小文件，行业里叫"根提示文件"（root hints）。相当于每本电话簿的第一页印着"总台电话"，这一页是印刷厂直接印上去的，不需要你查任何东西就能看到。这份文件极少变动，变了各家软件跟着更新一次即可。

根这一层还有一个常见误解值得澄清："全世界只有 13 台根服务器"是错的。准确说法是根服务器有 13 个"标识"（按字母命名，从 a 到 m），但每一个标识背后是分布在全球许多地点的大量实机，靠任播（Anycast，很多台机器宣告同一个地址，网络自动把你导向最近那台）共用同一个地址对外服务。好比一家连锁银行全国统一客服号 95XXX，你在哪个城市打过去，接的都是当地的话务中心。"13"是编号的数量，不是机器的数量。

为什么是 13 个：一个被 512 字节逼出来的数字

这个数字背后有一段很有意思的技术史，值得知道，因为它解释了 DNS 早期一个重要的设计约束。

RFC 1035 规定：DNS 使用 UDP 时，一个报文的载荷上限是 512 字节。这个限制的来源是当年对"任何 IP 网络都必须能不分片地送达的最小包"的保守估计——上一节讲 UDP 时提过，包一旦被切片，任何一片丢了整个包全废，而 UDP 不会重传。所以早期 DNS 干脆把消息限制得足够小，保证永远不需要切片。

于是问题来了：根服务器的清单必须塞进 512 字节里。一条记录要写服务器名字（比如 a.root-servers.net）加上它的 IPv4 地址，算下来 512 字节最多能装十三条。"13"这个数字不是设计美学，是一个被信封大小逼出来的答案——相当于一个信封最多只能塞十三张名片，不是因为十三吉利，是因为第十四张就封不上了。

这个 512 字节的限制后来被扩展机制解除了。EDNS(0)（Extension Mechanisms for DNS，DNS 扩展机制，规范是 RFC 6891）让客户端可以声明"我能接收更大的 UDP 响应"，从而突破 512 字节。但这里有个现实的工程权衡：

实践中的做法是三者结合：先用 UDP 问、声明一个不太激进的接收缓冲、如果响应还是装不下，服务器就在回复里点上"截断"标志（TC 位，Truncated），客户端看到后自动改用 TCP 重问一次。这套机制的意思是：DNS 从来不是"只用 UDP"，它是"默认用 UDP，装不下就换 TCP"——两者都用 53 端口。

换成大白话：好比寄东西默认用明信片（快、便宜、一张搞定），东西太多装不下时才改寄包裹（慢一点，但没有容量限制）。此外还有一类操作规范上就必须用 TCP：主从服务器之间同步整个区的全部记录（区域传送），因为数据量天然很大。

缓存：DNS 真正的性能秘密

如果每次访问网页都要跑完根 → TLD → 权威这一整条链，互联网早就瘫了。DNS 能撑住全球规模，靠的不是服务器多快，而是绝大多数查询压根没走到远处。

缓存在 DNS 里是层层设防的，从你按下回车那一刻开始，答案可能在五个不同的地方被截住：

注意第 ③ 层的特殊性。hosts 文件不是缓存，它是手工写死的覆盖——查询压根不会发出去。它的优先级通常高于一切 DNS 查询（具体顺序由系统配置决定，多数系统默认先查 hosts）。相当于你在通讯录官方名册上用笔划掉一行、自己手写了个新号码——从此这个人的号码你只认自己写的那个。开发时把某个域名临时指到本机（127.0.0.1）来做测试，就是用这一招。

缓存命中率有多高？这个数字很能说明问题：一台服务良好的递归解析器，缓存命中率通常在八成以上。也就是说十次查询里有八次压根不需要出门，直接从本地便签本上抄出来。

把这个账换算成可感知的量：假设一次完整的递归解析要走三跳、每跳三十毫秒，总共大约一百毫秒（差不多是你眨一次眼的时间）；而缓存命中只要一两毫秒。相当于本来要下楼跑三个窗口，现在低头看一眼手边的便签——这个差距在你打开一个含几十个第三方资源的网页时会被放大几十倍。

还有一个容易被忽略的缓存种类：否定缓存（Negative Caching，把"这个名字不存在"这个结论也存起来），规范见 RFC 2308。为什么要缓存"没有"？因为程序打错域名、或者某些软件反复查一个不存在的名字，这类查询量非常大。相当于前台被问过一次"贵公司有没有姓诸葛的员工"，答案是没有，那她会把这个"没有"也记下来——下次同样的问题不用再全楼问一圈。否定缓存的有效期由权威服务器在区配置里的一个参数决定。

TTL：保质期定多长，是一门取舍

TTL（Time To Live，存活时间——这条答案还能用多少秒）是权威服务器随答案一起给出的一个数字。所有缓存它的人都必须遵守：到期就作废，下次重新去问。

它的取值是一个非常典型的工程取舍，而且这个取舍你在生活里天天做：

换成大白话，TTL 就是超市货架上贴的那个保质期：写得短，顾客常来换新的，货损小但你得频繁补货；写得长，你省事了，可万一这批有问题，召回要花很久才能传遍所有货架。

这里有一条实操经验值得记住，因为它是无数次网站迁移事故的教训总结：要改 IP 之前，先把 TTL 调短，等旧的长 TTL 全部过期之后再动手改地址。

【网站迁移的正确 TTL 操作顺序】

假设当前 TTL = 86400（一天）

❌ 错误做法：直接改 IP
   → 全世界的缓存里还存着旧 IP，最长要等 24 小时才全部换掉
   → 这 24 小时里，一部分用户访问新机器、一部分访问旧机器
   → 数据两边写、用户投诉"有时能登录有时不能"

✅ 正确做法（提前三天开始）：
   第 1 天：把 TTL 从 86400 改成 300（五分钟）
           ↑ 注意：这个"改 TTL"本身也要等旧的 86400 过期
             才会被所有缓存看到，所以要提前一天以上
   第 2 天：确认全世界都已经在用 300 秒的短 TTL
   第 3 天：改 IP 地址
           → 五分钟后全世界基本切换完毕
   第 4 天：确认稳定后，把 TTL 调回 3600 或更长

★ 迁移期间旧机器不要立刻关！
  保留至少一天，让极少数不守 TTL 的顽固缓存有个软着陆。
  （现实中确实存在不遵守 TTL 的实现和中间设备）

最后那条提醒不是多余的。TTL 是一个"请求所有人配合"的约定，而不是一个能强制执行的规则——缓存方要是不守规矩，你完全没有办法。好比你在便签上写了"一小时后作废"，可看便签的人愿不愿意撕，你管不了。所以正经的迁移方案永远要给"顽固缓存"留后路。

记录类型：你到底想问什么

DNS 不只回答"这个名字的 IP 是什么"。它更像一本多栏目的名册：同一个名字下面可以登记地址、邮箱、别名、备注等好几种信息。你查的时候必须说清"我要哪一栏"，这一栏叫记录类型（Record Type）。

打个比方：你问前台"老张的联系方式"，前台会反问一句"您要他手机、办公室内线、还是邮箱？"——这三个都是"联系方式"，但是三条不同的记录。DNS 里也是一样，问 A 记录和问 MX 记录得到的是完全不同的东西。

其中 CNAME 有几条容易踩的坑，值得单独说，因为它是配置 DNS 时最常出错的地方：

• CNAME 会让查询多走一跳你查 www.example.com 得到"它其实是 xxx.cdn-provider.net"，然后还得再查一次那个名字才能拿到真地址。相当于寄信到旧地址，邮局贴了张转投单，信件又跑了一趟。所以 CNAME 链太长会明显拖慢首次访问。
• 同一个名字上，CNAME 不能和别的记录共存这是规范的硬要求。逻辑上很好理解：你既说"这个名字其实是另一个名字"，又说"这个名字的地址是某某"——这两句话互相矛盾，机器不知道该听哪句。好比门上同时挂着"本店已搬迁至隔壁"和"本店照常营业"两块牌子。
• 根域名（不带 www 的那个）通常不能用 CNAME因为根域名上必然已经有 SOA 和 NS 记录了，而 CNAME 不许和它们共存。这就是为什么很多人配 example.com（不带 www）指向 CDN 时会遇到麻烦，各家 DNS 服务商为此发明了各种非标准的替代方案（常见名字有 ALIAS、ANAME、CNAME flattening 等，具体名称和行为因服务商而异）。

再说说 TXT 记录，它是这张表里最"不像 DNS"的一项：它的内容就是一段随便写的文字，DNS 本身完全不理解那段文字是什么意思。相当于名册后面留了一栏"备注"，你想写什么写什么，看的人自己约定怎么解读。正因为这份自由，TXT 承载了大量后来才发明的用途——最典型的是域名归属证明：某个服务要你证明"这个域名真是你的"，它给你一串随机字符串，要求你把它写进 TXT 记录里。能写进去，就说明你有这个域名的管理权，因为只有域名主人能改 DNS 记录。这个手法非常朴素但极其有效。

DNS 报文长什么样

DNS 的消息格式定义在 RFC 1035 里，查询和响应用的是同一个格式——这是它的一个巧妙设计：服务器收到查询后，不用另造一个响应结构，只需要在原报文上填空、改几个标志位、追加答案段即可。

【DNS 报文结构：查询和响应共用同一格式】

+---------------------------------+
|            报文头（12 字节）    |
+---------------------------------+
|      问题段 Question            |  ← 你问了什么（名字 + 类型 + 类）
+---------------------------------+
|      回答段 Answer              |  ← 答案在这
+---------------------------------+
|      权威段 Authority           |  ← "去问这几台"的线索
+---------------------------------+
|      附加段 Additional          |  ← 顺手给的额外信息（见下方"胶水记录"）
+---------------------------------+

【那 12 字节的报文头里都有什么】

 ID（16 位）        这次问答的流水号。因为 DNS 走 UDP 且无连接，
                    收到回复时必须靠这个号码对上"这是我哪个问题的答案"。
                    ★ 这个字段后面讲安全时是关键角色。

 标志位（16 位）：
   QR   0=查询 1=响应
   OPCODE  操作类型（普通查询 / 反向查询等）
   AA   Authoritative Answer，"这答案是我这个正主给的"
   TC   TRuncated，"太长装不下，被截断了，请改用 TCP"
   RD   Recursion Desired，"我希望你替我递归查到底"
   RA   Recursion Available，"我这儿提供递归服务"
   RCODE 返回码：0=成功 2=服务器故障 3=名字不存在（NXDOMAIN）…

 四个计数（各 16 位）：问题数、回答数、权威数、附加数

★ 一个纯查询包通常只有几十字节 —— 比这段文字还短。
  也正因为如此，DNS 才敢每次都用一个 UDP 包直接问，
  不值得为几十字节先握手建连接。

报文头里的 ID 字段值得特别记住，因为它同时是 DNS 的效率来源和安全弱点。为什么要这个号？因为 UDP 无连接——你连着发了五个查询出去，回来五个包，操作系统怎么知道哪个答案对应哪个问题？靠这个流水号。相当于你在洗衣店存了五件衣服，店家给你五张不同编号的取衣票——凭票取衣，不会混。

问题在于：只要有人能猜中这个号码（以及你用的源端口），就能伪造一个假答案抢在真答案之前送到你手上。这是后面"DNS 缓存投毒"那一节的技术地基，先在这里埋个伏笔。

还有一个概念叫胶水记录（Glue Record），藏在"附加段"里，它解决的是一个鸡生蛋的死循环：

【胶水记录解决的死循环】

.com 服务器告诉你：
  "example.com 的答案去问 ns1.example.com"

问题来了：你怎么知道 ns1.example.com 在哪？
  → 要查 ns1.example.com 的地址
  → 而它属于 example.com 这个域
  → 而查 example.com 又得先找到 ns1.example.com
  → 死循环！

【解法：胶水记录】
.com 服务器在回复的"附加段"里顺手带上：
  ns1.example.com 的 A 记录 = 198.51.100.10
  ↑ 严格说它不属于 .com 管的范围，
    但它必须提供，否则链条断在这里。

★ 换成大白话：好比 12 楼秘书说"你去问 1203"，
  但她知道你压根不认路，于是顺手加一句
  "1203 在电梯出来右转第三间"。
  这句"顺手加的"就是胶水记录 ——
  它不是她的职责范围，但没它你就卡住了。

这也解释了为什么域名注册时，注册商会要你同时填"服务器名字"和"服务器 IP"——那个 IP 就是要拿去当胶水记录用的。

反向解析：从 IP 倒着查名字

前面讲的都是"名字 → 地址"。反过来行不行——给一个 IP，查它对应什么名字？行，这叫反向解析（Reverse DNS Lookup），但它的实现方式相当别扭，理解它反而能加深你对 DNS 结构的把握。

为什么别扭？因为 DNS 这棵树是按名字的层级组织的，从右往左越来越大。可 IP 地址的层级是从左往右越来越小（203.0.113.5 里最左边的 203 范围最大）。两套结构方向正好相反，硬塞不进去。

解法非常朴素，也很聪明：把 IP 地址倒着写，然后挂在一个专门的后缀底下。

【反向解析怎么做】

要查 203.0.113.5 对应什么域名？

① 把四段倒过来：5.113.0.203
② 加上专用后缀：5.113.0.203.in-addr.arpa
③ 查这个名字的 PTR 记录

现在它就变成了一个普通的域名查询，
完全可以复用 DNS 的整套树形结构和委派机制：
  .arpa           → 顶层
  in-addr.arpa    → 专门放 IPv4 反向解析
  203.in-addr.arpa    → 归管理 203.x.x.x 这一大块的机构
  0.203.in-addr.arpa  → 再往下委派
  ...

★ 为什么要倒着写？
  因为 DNS 的委派方向是"从右往左"，
  而 IP 的归属方向是"从左往右"。
  倒过来写，两者方向就对齐了 ——
  相当于把地址从"北京市 海淀区 1 号"
  改写成"1号 海淀区 北京市"，
  好让它跟域名一样从大到小往右排。

【IPv6 更夸张】
  IPv6 反向解析用 ip6.arpa，
  而且是逐个十六进制位倒着写，
  一个地址能写成几十段用点隔开的单字符 ——
  写出来非常长，但原理完全一样。

反向解析在日常上网里用不上，但在两个场景里很关键：

• 邮件服务器的可信度检查收信方常会检查"发信的这个 IP，反查出来的名字和它自称的域名对不对得上"。对不上的往往被当成垃圾邮件。相当于快递员上门自称是某公司的，你打电话到那家公司核实一下确有此人——这是一道很基础但很有效的验证。
• 运维排查日志里一堆 IP 看不出所以然，反查成域名就能大致看出"这是某家云、某个爬虫、某个地区的用户"。

要注意一个常见误解：正向记录和反向记录是两套独立配置的东西，它们不会自动对应。你把 example.com 指向某个 IP，并不会让那个 IP 反查出 example.com——反向记录得由拥有这段 IP 的人（通常是你的云服务商或运营商）来配。相当于你在自己通讯录里给某个号码起了名字，这不会改变电话局登记的户主是谁。

DNS 的原罪：一张谁都能看、谁都能改的明信片

前面讲的全是"它怎么工作"。现在讲"它为什么不安全"——这一节是理解 DoH、DoT、DNSSEC 这些新东西的前提。

1987 年设计 DNS 的时候，互联网只有几百台机器、彼此互相认识，压根没有"防坏人"这个需求。所以原始 DNS 有三个先天特征，在今天看来都是漏洞：

• 特征一 · 明文传输你查什么名字，查询包里是直接写着的字符串，路上任何一台设备都能看清。相当于寄明信片——不用信封，字全写在外面，谁经手谁都能看一眼。
• 特征二 · 无来源认证你收到一个答案，没有任何办法验证"这答案真是那个正主给的"。原始协议里没有签名、没有身份校验，你只能凭"这个包的流水号对得上、来源地址端口对得上"就信了。相当于收到一张明信片，上面写着"我是老张，我的新号码是 XXX"——你只能靠字迹和邮戳猜真假。
• 特征三 · 默认走 UDP，一问一答UDP 无连接、没握手，源地址可以随便伪造。这让"抢先给一个假答案"这件事在技术上非常容易。

三条合在一起，产生了两类完全不同的后果，一定要分清楚：

这张表最重要的一点是：加密和签名解决的是两件不同的事，谁也替代不了谁。加密让别人看不见你查了什么；签名让你能验出答案是否被动过。好比寄一份重要文件：装进不透明的密封袋（加密）解决"别人偷看"，签名盖章（签名）解决"内容被换"。你需要哪一样，取决于你担心的是哪件事——通常两样都需要。

缓存投毒：抢先给出一个假答案

这是 DNS 历史上最著名的一类攻击，理解它能让你彻底明白"为什么需要加密和签名"。

攻击的基本思路极其朴素：DNS 是"谁先答，我就信谁"——因为它压根没有验证正主的能力。所以攻击者要做的只是抢在真答案回来之前，把一个假答案塞给解析器。而解析器不但会用它，还会存进缓存——于是之后所有向它查询的人都会拿到这个假地址，直到 TTL 过期。这就是"投毒"这个名字的来源：污染了水源，喝这口井的人全中招。

【缓存投毒的原理骨架】

正常流程：
  解析器 ──查询──> 权威服务器
         <──答案── （带流水号 ID=12345）
  解析器核对：ID 对得上、来源对得上 → 采信 + 存缓存

攻击者要做的：
  ① 想办法让解析器发起一次查询（比如让它去查一个还没缓存的名字）
  ② 在真答案回来之前，伪造一批响应包发给解析器
     - 源地址伪造成权威服务器的地址（UDP 可以做到）
     - 流水号靠猜（原始设计里这个空间不大）
  ③ 只要有一个猜中，解析器就采信 + 写进缓存
  ④ 之后所有用这台解析器的人，都拿到攻击者指定的地址

【关键在于这是一场赛跑】
  攻击者必须赶在真答案之前到达。
  一旦真答案先到并被缓存，这一轮就失败了，
  而且要等 TTL 过期才有下一次机会。

【已部署的缓解手段】
  ① 源端口随机化（每次查询用随机源端口）
     → 攻击者要同时猜中"流水号 + 端口号"
  ② 大小写随机化（把查询名字的字母随机大小写，
     答案里必须原样返回 —— 又多一道要猜的东西）
  ③ 缓存已有条目时不轻易被覆盖
  ④ ★ 根本解法：DNSSEC 让答案带可验证的签名

★ 注意用词：以上手段是"把猜中的概率压到极低"，
  不是"从原理上不可能"。这个区别很重要 ——
  概率性防御和密码学防御是两个不同层次的东西。

DNS 污染：为什么明文查询天生可被中间篡改

这一节只讲技术原理，不涉及任何具体规避方法，也不做价值评判——理解机制本身就够了，因为它能解释你在网上遇到的很多现象。

前面说清了两个事实：一，DNS 查询默认是明文的 UDP 包；二，原始 DNS 没有办法验证答案是否来自正主。把这两条放在一起，就得到一个纯技术性的结论：

路径上任何一台能看到你 DNS 查询包的设备，原理上都可以抢先返回一个响应，而你的电脑无法区分它和真答案。

这类现象在网络工程里统称 DNS 污染 / DNS 篡改（DNS Spoofing / Tampering）——说白了就是：你寄出去的是一张明信片，路上有人看了内容，然后先你一步寄回来一张假的回信。你收到的这张回信格式完全正确、流水号完全对得上，你的电脑没有任何依据说它是假的。

为什么"抢先"这么有效？因为解析器的逻辑是"收到第一个格式正确、流水号匹配的响应就采信，后面再来的一律丢弃"。好比你在邮局等一封回信，先到的那封被你拆开看了、照着办了，后到的那封真信你就当重复件扔了。而中间设备天然占据"离你更近"的位置，抢先几乎是必然的。

这类篡改在技术上有几种可辨识的表现，知道这些能帮你排查问题：

那 DoH 和 DoT 改变了什么？这是本节的重点，也是它们被发明出来的直接动机。

把查询装进加密通道之后，两件事同时发生了变化：一，路径上的设备看不到你在查什么名字了（因为内容被加密）；二，它也没法伪造响应了（因为它没有加密通道的密钥，造不出一个能被你的客户端接受的包）。

换成大白话：明信片换成了密封的挂号信，而且这封信只有你和收件人两个人有钥匙。沿路的人既看不见内容，也没法往里塞一张假的——因为他造不出那把锁。

但请注意加密带来的信任转移，这一点特别重要，很多人只记住"加密更安全"而忽略了它：

• 加密不等于匿名你和解析器之间的路径被保护了，但解析器本身完全知道你查了什么。相当于你把明信片换成了密封信——沿路的邮递员看不见了，但收信人当然看得见。所以问题变成了"你信任哪个收信人"。
• 信任对象从"运营商"换成了"解析器提供方"用加密 DNS 意味着你把"我访问了哪些网站"这份信息交给了某个公共 DNS 服务商。这不是"更安全"或"更不安全"，这是"换了一个你要信任的对象"。做选择前该看的是它的隐私政策和日志留存策略。
• 加密的是查询过程，不是你的访问本身即使 DNS 查询被加密了，你接下来去连接那个 IP 地址这件事，路径上的设备照样看得见。加密 DNS 保护的只是"查号"这一步。

最后一条常被误解，值得再强调一遍：加密 DNS 不是隐身衣，它只是把"你在查号簿上翻了哪一页"这件事挡住了。你接下来去了哪栋楼，站在门口的人照样看得见。

DoH 与 DoT：把查号过程装进密封信

两个协议做的是同一件事——加密 DNS 查询——但装法不同，而这个不同带来了相当不一样的现实后果。

把这个区别翻译成人话：DoT 好比寄挂号密封件——信封是密封的，但信封样式一看就知道"这是挂号件"。DoH 好比把那封密封信塞进一个和其他几万个普通包裹一模一样的箱子里——从外面看，它和别人网购的箱子没有任何区别。

两者的技术优劣其实没有定论，因为它们优化的目标不同。DoT 更"守规矩"——它承认网络管理者有管理 DNS 流量的正当需求（企业要拦恶意域名、学校要做内容过滤），所以给了一个明确的端口让人管理。DoH 更"抗干扰"——它优先保护用户不被中间设备干预，代价是让所有正当的和不正当的 DNS 管理手段一起失效。这是一个典型的"同一个技术特性，站在不同位置看到完全相反的评价"的例子。

还有第三个方案值得一提：DoQ（DNS over QUIC，RFC 9250）——把 DNS 装进上一节讲过的 QUIC 里。它的动机很直接：DoT 和 DoH 都跑在 TCP 上，而 TCP 要先握手，这让本来一个来回就能搞定的查询变成了好几个来回。QUIC 的握手更快，还没有队头阻塞的问题——对"一问一答、包很小、延迟敏感"的 DNS 来说非常合适。相当于从"打电话前要先确认三遍才能说话"变成"接通就能说第一句"。

实际使用中还有一个很现实的细节：加密 DNS 有一个"鸡生蛋"问题。你要连到 dns.example.com 这个加密 DNS 服务，得先知道它的 IP——可查这个 IP 又需要 DNS。解法是直接用 IP 地址配置（这就是为什么公共 DNS 都用极好记的地址，比如 8.8.8.8 和 1.1.1.1——好比消防和急救用三位号码，就是为了在你什么都记不住的时候还能拨出去），或者由系统在首次连接时用普通 DNS 引导一次。

DNSSEC：给答案盖一个能验的章

加密解决"别人看得见"，签名解决"答案被换过"。DNSSEC（DNS Security Extensions，DNS 安全扩展，规范是 RFC 4033 / 4034 / 4035）干的是后一件事。

它的核心思路一句话就能说清：权威服务器给每条记录加一个数字签名，你拿到答案后自己验签。签名对不上，说明这条记录被动过，直接丢弃。

换成大白话：好比每份公文上都盖一个只有正主刻得出来的印章，而且这个章的真伪任何人都能当场核验。有人半路换了内容，章就对不上了。

但 DNSSEC 有一个更精妙的部分，也是它真正的难点：你凭什么相信那个印章本身是真的？答案是信任链（Chain of Trust）——一层给一层作保，一路保到根。

【DNSSEC 的信任链：一层保一层】

根（.）
 │  根的公钥是"信任锚"，预置在解析器软件里
 │  ↓ 根用自己的私钥，为 ".com 的公钥摘要" 签名
 │
.com
 │  → 于是你验完根的签名，就相信了 .com 的公钥是真的
 │  ↓ .com 用自己的私钥，为 "example.com 的公钥摘要" 签名
 │
example.com
 │  → 于是你相信了 example.com 的公钥是真的
 │  ↓ example.com 用自己的私钥，为它的每条记录签名
 │
最终答案（A 记录 = 93.184.216.34 + 签名）
    → 用已经验证过的 example.com 公钥去验这个签名
    → 通过 = 这条记录确实是正主给的、且一个字节都没被改过

★ 换成大白话：
  好比办证要一层层担保 ——
  国家承认省的公章，省承认市的公章，
  市承认区的公章，区给你的证件盖章。
  你只要认得国家那个章（这个章是刻在你手上的，
  不需要问任何人），整条链就能一路验到底。

★ 唯一需要"无条件相信"的只有根的公钥。
  它不通过网络获取，而是随软件一起发布 ——
  这叫信任锚（trust anchor）。
  相当于身份证防伪的那套原始基准，
  是印刷厂直接给你的，不是网上下载的。

DNSSEC 的部署没有加密 DNS 那么普及，原因是相当现实的工程问题，值得如实列出来：

• 响应变大很多每条记录都要带签名，响应体积显著膨胀，更容易超出 UDP 的舒适区，触发分片或转 TCP。这既影响性能，也放大了被利用做反射攻击的风险。
• 运维复杂度高要管密钥、要定期轮换密钥、要保证轮换期间新旧签名都有效。密钥轮换配置出错会让整个域名直接解析失败——不是"变慢"，是"彻底打不开"，因为验签失败的记录会被直接丢弃。相当于换门锁的时候换错了，全家谁都进不去。
• 整条链上必须每一层都部署了才有意义链条上任何一环没签名，从那里往下的验证就断了。这是典型的"网络效应"问题：早期部署者拿不到多少好处，得等大家都上。
• 它只保证"答案没被改过"，不保证"内容是好的"这一点常被误解：DNSSEC 能证明这条记录确实出自正主，但如果正主本身就是个钓鱼网站的主人，签名照样是有效的。好比印章能证明这份文件确实是某人写的，但不能证明他写的是实话。

把三样东西的分工放在一起看，就彻底清楚了：

三者是三道独立的关卡，位置不同、职责不同、缺一不可。这也解释了为什么即便 DNS 被篡改，HTTPS 也常常能救你一命——因为你被导到假服务器上之后，那台假服务器拿不出这个域名的有效证书，浏览器会当场报警。相当于有人骗你走进了错的门，但门里的人拿不出这家公司的营业执照，你立刻就知道走错了。这一层会在第 8 章讲证书时展开。

DNS 顺便干的那些活：负载均衡、就近调度、灰度发布

DNS 表面上只是"查号"，但因为它处在每一次访问的最前面，就自然成了一个极好的"调度入口"。相当于所有客人都必须先到前台问路——那么前台想把谁引到哪儿，就完全由它决定。这一层能力被用出了很多花样。

"就近调度"那一行的局限值得展开讲，因为它是一个很有意思的现实问题。权威服务器看到的请求，来源不是你，而是你用的那台递归解析器。所以它做的"就近"是"离你的解析器最近"，而不是"离你最近"。

换成大白话：你让在上海出差的同事帮你在总部前台问路，前台看他是从上海打来的，就给了他上海分部的地址——可你人在北京。这就是为什么"换个公共 DNS 之后，视频加载反而变慢了"这类现象会发生：你的查号被送到了很远的地方，于是给你分配的服务器也在很远的地方。

为了缓解这个问题，业界搞了一个扩展叫 EDNS Client Subnet（ECS，客户端子网扩展，RFC 7871）：解析器在转发查询时，顺手带上"提问者大致属于哪一段网络"这个信息（只带网段前缀，不带完整地址）。相当于同事在问路时补一句"其实我这位朋友在北京海淀一带"，前台就能给出对的分部地址了。

这里又出现一个典型的取舍：ECS 提升了调度精度，但它把你的大致位置信息透露给了权威服务器。所以有些注重隐私的公共 DNS 默认不发送 ECS，代价就是就近调度的精度下降。又是一次"精准"和"隐私"的直接对撞——网络里这种取舍到处都是，几乎没有一处是免费的。

动手查 DNS：五条命令搞清一切

前面讲的所有东西，都可以在自己电脑上验证一遍。下面这几条命令是排查 DNS 问题的全套家当，值得记住。

# ① 最常用：查一个域名的地址（Linux / macOS）
$ dig example.com

;; QUESTION SECTION:
;example.com.            IN  A
;; ANSWER SECTION:
example.com.    3600    IN  A    93.184.216.34
                 ↑ 这个数字就是剩余 TTL（秒）
                   多查几次，你会看到它在递减 —— 那说明是缓存命中
;; Query time: 2 msec       ← 2 毫秒 = 命中缓存
;; SERVER: 192.168.1.1#53   ← 实际是谁回答的

# ② 指定用某台解析器来查（对比不同解析器的答案是否一致）
$ dig @8.8.8.8 example.com
$ dig @1.1.1.1 example.com
   ↑ 两者答案不一致时，说明中间有人给出了不同的结果

# ③ 查特定类型的记录
$ dig example.com MX          # 邮件服务器
$ dig example.com NS          # 这个域由谁负责
$ dig example.com TXT         # 文本记录
$ dig example.com AAAA        # IPv6 地址
$ dig example.com SOA         # 区的管理信息

# ④ ★ 最能说明问题的一条：完整跟踪整条查询链
$ dig +trace example.com
   → 它会绕过缓存，从根开始一步一步问下来，
     把"根 → .com → example.com"每一跳都打出来。
   → 前面讲的迭代查询，这一条命令就能亲眼看全过程。

# ⑤ 反向解析
$ dig -x 93.184.216.34
$ nslookup 93.184.216.34

# 【Windows 用户】
> nslookup example.com
> nslookup -type=MX example.com
> nslookup example.com 8.8.8.8        # 指定解析器

# 看本机 DNS 缓存
> ipconfig /displaydns
# 清空本机 DNS 缓存（改了 hosts 或迁移后不生效时的第一招）
> ipconfig /flushdns

# 【macOS 清缓存】
$ sudo dscacheutil -flushcache
$ sudo killall -HUP mDNSResponder

# 【Linux 清缓存】具体命令因所用解析服务而异，
# 用 systemd-resolved 的系统常见：
$ sudo resolvectl flush-caches

dig +trace 这条命令强烈建议你亲手跑一次，因为它把这一节最抽象的部分变成了可以看见的东西：你会亲眼看到查询先问根、根说"去问 .com"、.com 说"去问某某"、最后才拿到答案——一整条迭代链条在屏幕上打出来。读十遍文字不如看一次输出。

再给一张排障对照表，把"你看到的现象"映射到"大概是哪一环出了问题"：

倒数第三行那个判断特别实用，值得单独记住："IP 能通、域名不通"几乎就是 DNS 问题的诊断标准——因为这说明数据能到达对方，只是"查号"这一步失败了。相当于你照着门牌号找过去人在家，但打电话过去查号台说"查无此人"——路是通的，问题在查号台。

常见误解澄清

最后收几个流传很广但不准确的说法。

• 误解一："DNS 只走 UDP"不对。DNS 默认用 UDP，但响应装不下时会转 TCP，区域传送必须用 TCP，加密方案 DoT / DoH 也都跑在 TCP 上。准确说法是"以 UDP 为主，按需要用 TCP"。
• 误解二："全世界只有 13 台根服务器"不对。是 13 个标识（a 到 m），每个标识背后靠任播分布在世界很多地点。13 是编号数量，不是机器数量。
• 误解三："换个公共 DNS 一定更快"不一定。公共 DNS 可能离你更远，而且会影响就近调度的准确性（前面讲 ECS 时说过）。它可能让"查号"这一步变慢，也可能让"下载"那一步变慢。值得实测对比，而不是照搬建议。
• 误解四："DNS 解析出来的 IP 是固定的一个"不对。大网站通常返回多个地址，而且不同地区、不同时刻返回的可能完全不同。你和邻居查同一个网站，很可能拿到不同的答案，两个答案都是对的。
• 误解五："DNSSEC 能防钓鱼网站"不能。它只保证"这条记录确实是正主给的、没被改过"。钓鱼网站的域名归钓鱼者所有，它给自己的记录签名完全合法。防钓鱼要靠别的手段。
• 误解六："改完 DNS 记录马上就生效"不对。受全世界各级缓存的 TTL 制约，生效是一个逐步扩散的过程。相当于发了通知，但各部门看到公告板的时间不一样。这就是为什么迁移要提前调短 TTL。
• 误解七："域名里的大小写有区别"没有。DNS 查询在比较名字时不区分大小写（Example.COM 和 example.com 是同一个名字）。但响应必须原样返回你写的那个大小写形式——这个特性后来被用来做了一层反投毒防护（前面提过的"大小写随机化"）。

最后，把 DNS 放回整个访问流程里定个位，为下一章做个铺垫：你在浏览器地址栏敲下回车之后，DNS 是第一个真正发出网络请求的环节——它之前只有浏览器自己在本地忙活，它之后才轮到建立连接、加密握手、发请求。第 4 章会把这整条路完整走一遍，届时 §4.2 会专门讲"这一步在实际访问中是怎么串起来的"。这一节讲的是协议本身，那一节讲的是它在流程里的位置。