# 一根没完没了的查询：DNS凭什么撑住整个互联网 ## 导语：为什么你该重看一次 DNS 每天全球要发生**数万亿次 DNS 查询**，但它几乎从不出错——这件事本身比"它出了什么新闻"更值得惊叹。Hussein Nasser 在他的后端工程节目 *The Backend Engineering Show* 里用 42 分钟把 DNS 从里到外拆了一遍，标题叫 **"DNS is Beautiful"**。这期视频的好看之处不在于科普"DNS 是什么"，而在于它把 DNS 当成一个**工程作品**来品评：一个诞生于 1983 年、最初只是为几百台主机设计的协议，凭什么在四十年后还能扛住几十亿设备？ 更劲爆的是视频最后那段真实历史：**Google Chrome 的一个"无害"小功能，让全球 13 组根服务器（root server）白白多干了 12 年的活**。这不是漏洞，也不是攻击，而是"每个客户端都觉得自己只多做了一件小事"的累积灾难。如果你做后端、做架构、做任何会被海量客户端调用的系统，这期视频给你的不是一个知识点，而是一面镜子。 ## 视频背景卡片 | 项目 | 内容 | |------|------| | 视频标题 | DNS is Beautiful（The Backend Engineering Show） | | 频道 | Hussein Nasser（后端工程方向知名教育者） | | 时长 | 约 42 分钟 | | 播放量 | 10 万+ 级（2022 年发布，长期热门 evergreen） | | 核心主题 | DNS 的分层设计哲学、UDP 取舍、缓存与投毒、分布式真相、以及客户端行为对共享公共设施的冲击 | ## 核心内容拆解 ### 一、DNS 的"美"来自三件极简之事的叠加 Hussein 反复强调一句话：DNS 之所以能 scale 到全球，不是因为它有多复杂，而是因为它**足够笨、足够分层、足够可丢弃**。把它抽象一下，整个系统只在做三件事： 1. **把名字组织成一棵树**——`www.example.com` 是从右往左读的层级，`.`（根）→ `.com`（TLD）→ `.example`（注册域）→ `www`（主机）。每一层只负责"指路"，把自己不知道的查询往下一层甩。 2. **在每一层都缓存**——解析器、操作系统、浏览器、甚至家里的路由器，全都在按 TTL 缓存。这把一个本质上是"全球共享数据库"的东西，变成了**最终一致（eventually consistent）的边缘缓存网络**。 3. **查询本身无状态、走 UDP**——没有握手、没有连接状态、来一个包答一个包，答不出来就当没听见。 我的延伸判断是：这三条加起来，DNS 其实是世界上**最早、最成功的"行星级只读数据库"**。它用"层级委派 + 边缘缓存 + 无状态协议"这三板斧，解决了 CAP 定理里"高可用 + 分区容忍"的取舍——代价是放弃强一致性（改了记录要等 TTL 过期才全球生效）。理解了这个底层模型，你就理解了为什么后来 CDN、对象存储的元数据层、甚至很多服务发现系统，都在抄这套架构。 ### 二、一次查询的真实旅程：靠"指路"而非"知道" 视频第 7 分 40 秒讲细节：当你输入 `www.example.com` 时，发生的是一个**接力式的指路过程**，而不是某个中心节点"知道一切"。 本地解析器（resolver，可能是 ISP 的、也可能是 1.1.1.1 / 8.8.8.8）先查自己的缓存；没有，就去问根服务器。关键点在于——**根服务器并不知道 `www.example.com` 的 IP，它只知道"`.com` 这一段归谁管"**。于是根服务器回答："我不知道答案，但 `.com` 的事你去找这组 TLD（顶级域）权威服务器。" TLD 再回答："`.example` 你去找这个注册商的权威服务器。" 直到 `example.com` 自己的权威服务器返回真正的 A 记录（IP 地址），解析器再把它缓存起来交给浏览器。 ```mermaid flowchart TD A["浏览器/应用
查询 www.example.com"] --> B["本地解析器 Resolver
ISP 或 1.1.1.1 / 8.8.8.8"] B --> C{"缓存命中?"} C -->|"命中 TTL 未过期"| Z["直接返回 IP"] C -->|"未命中"| D["根服务器 . （13 个字母 / Anycast）"] D -->|"只指路:去问 .com"| E["TLD 权威
负责 .com"] E -->|"只指路:去问 example.com"| F["example.com 权权威服务器"] F -->|"返回 A 记录 IP"| B B --> G["写入缓存 按 TTL"] G --> Z style D fill:#ffd6d6 style F fill:#d6e8ff style G fill:#d6ffd6 ``` 这个过程里最反直觉的设计是：**没有任何一个节点掌握全貌，但合起来却拼出了完整的答案。** 这正是分层委派（hierarchical delegation）的威力——根服务器只维护大约一千多条 TLD 的"指路记录"，负担极小；真正的权威数据散落在全球数百万个权威服务器上。我自己写过微服务后最大的体会就是：你不需要一个"知道所有事"的中心服务，你需要一套"每个人只精通自己一层、并知道该把球踢给谁"的路由约定。DNS 把这个模式做到了极致。 ### 三、为什么偏要走 UDP：用"可丢弃"换"无限扩展" 视频第 15 分 44 秒回答了一个很多人没深想过的问题：DNS 为什么不用 TCP？ 答案是**控制面与数据面的取舍**。DNS 查询通常极小（一个域名 + 一个查询类型），响应也小。如果用 TCP，每次都要三次握手建立连接、维护连接状态、四次挥手拆除——为了传几十个字节，开销远大于负载本身。UDP 是"打完就跑"：发出去，对方收到就回，收不到就丢，**不维护任何连接状态**。这意味着根服务器可以同时处理天文数字级别的并发查询，而不用为每条连接占内存。 但 UDP 不是免费的午餐。原始 DNS 把单条响应限制在 **512 字节**以内（超过就得截断或改用 TCP 回传）。这在 1980 年代够用，但今天 DNSSEC（给响应加签名）会让响应包暴涨，于是有了 **EDNS0** 扩展，允许更大的包。我的延伸分析是：UDP 这个选择其实是把"可靠性"这个责任从协议层甩给了应用层——DNS 用"重试 + 缓存 + 幂等"来补足丢包。这套"宁可简单到丢弃、也不复杂到崩溃"的哲学，今天被 QUIC、被很多事件驱动架构反复致敬。 ### 四、缓存与 TTL：DNS 的"最终一致性引擎" DNS 能扛住全球流量，一半的功劳在缓存。但缓存也带来一个所有后端都头疼的问题：**数据改了，旧值多久才消失？** 答案是 TTL（Time To Live）。你在权威服务器上改了 IP，全球各地缓存里的旧值要等各自 TTL 到期才会刷新——这就是 DNS 版本的"最终一致性"。 视频顺带提醒：**TTL 不是越短越好，也不是越长越好**。设太短，缓存命中率暴跌，根服务器和权威服务器流量飙升；设太长，故障切换时全世界都要陪你等。实战中常见做法是"关键切换前先逐步把 TTL 调低"，等变更生效后再调回——这本质上是**用两阶段的 TTL 来模拟一次可控的灰度发布**。 Hussein 没展开但值得补一句的是 **negative caching**（对"不存在"的否定结果也缓存），它对防止"瞎查询洪流"至关重要，但也意味着一条误删的记录可能让一批用户在 TTL 内持续访问失败。 ### 五、DNS 投毒：当"打完就跑"成了攻击面 UDP 的无连接特性，恰恰是 DNS 投毒（poisoning）的温床。视频第 19 分 30 秒进入安全话题。 经典的 Kaminsky 攻击逻辑很精妙：DNS 查询里有一个 16 位的**事务 ID（Transaction ID）**用来配对请求和响应，但因为 UDP 无连接，攻击者只要抢在真实权威服务器之前，伪造一个"看起来对得上"的响应返回给解析器，解析器就会把这个假 IP 缓存下来。16 位 ID 只有 65536 种可能，加上旧实现还用**可预测的源端口**，攻击者枚举成功的概率被大幅放大。 防御手段随之进化：**源端口随机化**（让攻击者要猜的不仅是 16 位 ID 还有约 16 位端口）、**0x20 编码**（把查询名里的大小写随机混合，如 `WwW.eXaMpLe.CoM`，强制响应必须原样回传大小写，等于又给攻击者加了一道随机性的锁）、以及 DNSSEC（用密码学签名让解析器能验证响应真伪）。我的判断是：DNS 的安全史就是一部"用更多随机性对抗无连接协议先天脆弱性"的历史——每一个补丁都在不破坏原有简单性的前提下，给攻击者增加猜测成本。 ### 六、"分布式"这个词，被 DNS 用得很暧昧 视频第 24 分 10 秒抛出一个犀利问题：**DNS 真的算"分布式"吗？** 表面上是：数据散落在全球、没有单点全知。但严格说，**DNS 是"分层的权威委派"，不是 P2P 意义上的分布式**。`.com` 的权威集中由 Verisign 等机构负责，某个具体域名的权威服务器数量也有限。这意味着 DNS 存在**逻辑上的关键节点**——如果一组 TLD 权威或某个核心解析器被攻陷或被劫持，影响是结构性的、全球性的。 真正救了 DNS、让它物理上没有单点的，是 **Anycast**：全世界所谓"13 组根服务器"（a 到 m，13 个字母），实际上背后是**数千个物理实例**，它们共享同一个 IP 地址。你的查询包被 BGP 路由到**距离你最近**的那个实例。于是"逻辑上 13 个"和"物理上数千个"被解耦——攻击者想 DDoS 掉一个 IP，等于在和它背后一整个地理分布的实例集群对抗。这个设计堪称教科书级的"用 IP 层任播实现应用层水平扩展"。 ### 七、攻击者怎么把 DNS 当工具用：隧道、接管、依赖混淆 视频第 26 分 30 秒转向"DNS 被滥用"的更现实一面。攻击者早就发现：既然 DNS 几乎在所有网络里都畅通无阻（连很多受限网络也放行 53 端口），它就成了绝佳的**隐蔽通道**。 几种典型滥用：**DNS 隧道（tunneling）**——把数据塞进子域名字段，借 DNS 查询把信息偷渡出去或建立命令控制信道；**子域接管（subdomain takeover）**——某条 CNAME 指向了一个已被释放的云资源，攻击者重新申请该资源，从而"继承"这个子域的信任，常用于钓鱼和窃取 cookie；以及视频引用的 **Dependency Confusion 攻击**（Alex Birsan 的经典案例）——攻击者向公共包仓库注册一个和你私有仓库同名的包，因为你的构建系统在公私仓库之间解析依赖时遵循特定顺序，于是把你公司内部的"安全包"悄悄替换成公网上的恶意包，借此打进企业内网。这几个案例的共同点是：**它们都不在破坏 DNS 协议本身，而是利用 DNS"天然可信、天然放行"的地位做侧门**。对你做安全的启示是——把 DNS 当基础设施的同时，必须把它当一个**不可信边界**来监控。 ### 八、压轴真相：Chrome 让根服务器白干了 12 年 这是整期视频最有冲击力的故事，也是我选这期做深度解读的核心原因。视频最后（30 分 30 秒）引用了 APNIC 的一篇博客。 Chrome（其实是 Chromium 内核）为了**检测 ISP 是否在劫持/劫持 DNS**——比如公共 Wi-Fi 或某些运营商会把不存在的域名也重定向到广告页——内置了一个叫 **ABE（Aggressive Boundary / Bypass Detection）** 的功能：它会**主动生成一个 10 位随机字符串、几乎肯定不存在的域名**去查询。逻辑是：如果这么离谱的域名居然能返回一个 IP，那说明你的网络被劫持了。 听起来很合理、很"小"。问题是，全球几十亿 Chrome 用户、无数个标签页、无数次启动和重连，每个人都在**对根服务器发起一条注定 NXDOMAIN（域名不存在）的查询**。Chrome 还会同时生成大量前缀来提高检测可靠性。结果就是：**根服务器的流量里，相当大一部分是被这类"探测性 NXDOMAIN 查询"撑起来的**，而且持续了**约 12 年**。直到根服务器运营方（如 APNIC、Verisign 等）公开呼吁，Chromium 团队才逐步调整——比如改用更少的随机前缀、对结果做本地缓存去重等。 这个故事的三重启示，比技术细节本身更值钱： - **"无害的客户端优化"在十亿级规模下就是公共灾害。** 每个浏览器工程师都觉得"我就多发一个包"，乘以几十亿就是根服务器的洪流。这是工程界典型的**公地悲剧（tragedy of the commons）**。 - **被动免费的基础设施，承受了主动商业产品的外部成本。** 根服务器是社区志愿维护的公共设施，而 Chrome 是 Google 的商业产品。当一方免费、一方海量，成本就被前者默默吸收。 - **可观测性很重要。** 这个问题能被发现，恰恰是因为根服务器运营方有详尽的流量监控。没有度量，就没有改进。 ## 知识结构图：DNS 之美的三大支柱与两面性 ```mermaid mindmap root((DNS is Beautiful)) 美的三支柱 分层委派 名字是一棵树 每层只指路不全知 边缘缓存 每层都按TTL缓存 最终一致性 无状态UDP 打完就跑 可丢弃换扩展 两面性代价 放弃强一致 改记录等TTL 无连接的脆弱 投毒 Kaminsky 需DNSSEC/0x20 真相与教训 物理扩展靠Anycast 逻辑仍是分层非P2P Chrome害根服务器12年 客户端小优化=公地悲剧 ``` ## 实战启示：把这期视频装进你的工具箱 **如果你是后端/架构师**，请认真抄 DNS 的作业：把"中心必须知道一切"的执念放下，学会用**层级委派 + 边缘缓存 + 无状态协议**来设计任何读多写少的全球服务。你手里的 Redis、CDN、本地 LRU 三级缓存，本质上就是 DNS 缓存思想的微观重现；你纠结的"缓存怎么失效"，DNS 早就用 TTL + 两阶段降 TTL 给出了工程范式。 **如果你做运维/SRE**，记住两条铁律：第一，任何 DNS 变更都要**提前降 TTL、变更后观察、再恢复**，把它当成一次灰度发布；第二，**negative caching 要开但要监控**，否则一次误删会变成持续 N 秒/分钟的全网访问失败。配 Anycast 或多 resolver 时，注意 RRL（Response Rate Limiting）来稀释放大攻击。 **如果你做安全**，把 DNS 当一个**不可信但必须放行的边界**：启用 DNSSEC 验证、开启 0x20 与源端口随机化、监控异常的 TXT/超长子域查询（隧道特征）、定期扫描无主 CNAME 防止子域接管、在 CI 里对公私包仓库配置**优先级与 scope 白名单**挡住 Dependency Confusion。 **如果你是 SDK / 客户端开发者**，这条最重要：**永远问一句"如果全球每个用户都像我这么做一次，后端受得了吗？"** Chrome 的故事不是孤例。你每次"启动时多 ping 一下""每隔几秒探一下活""随机发个探测包"，乘以装机量都是基础设施的真实成本。在共享公共资源面前，客户端的"懒"和"克制"本身就是一种工程美德。 ## 延伸学习路径 1. **Hussein Nasser 的 Backend Engineering 系列**（YouTube @hnasr 及 udemy 课程）——他的网络、数据库、NGINX 系列是后端工程师的高密度补给，本期即出自该系列。 2. **Cloudflare Learning - DNS 系列**——从 *What is DNS* 到 *DNS cache poisoning* 再到 *SAD DNS explained*，是把本视频每个安全章节说透的免费资料。 3. **APNIC 官方博客：Chromium's impact on root DNS traffic**——视频引用的原始一手资料，想看 Chrome/根服务器流量之争细节必读。 4. **Alex Birsan - Dependency Confusion**（Medium）——理解攻击者如何利用 DNS + 包仓库解析顺序打进企业内网。 5. **RFC 1035（经典 DNS）→ RFC 7766（TCP 传输）→ RFC 8484（DNS over HTTPS）**——按时间顺序读，能清楚看到 DNS 如何从"裸 UDP"演进到"加密的 DoH/DoT"。 ## 一句话总结 DNS 的美，在于它用"分层委派、边缘缓存、无状态 UDP"三件最朴素的武器拼出了一座行星级数据库——而 Chrome 让根服务器白干 12 年的故事提醒我们：**在共享基础设施面前，每一个客户端的"小事"，都是真实的全球成本。** ## 参考来源 1. [DNS is Beautiful — Hussein Nasser, The Backend Engineering Show](https://www.youtube.com/watch?v=tgWx81_NGcg) — 本文分析的核心视频（42 分钟深度拆解） 2. [DNS is Beautiful（配套图文）— Hussein Nasser Substack](https://hnasr.substack.com/p/dns-is-beautiful-196) — 视频章节结构与引用资源 3. [Chromium's impact on root DNS traffic — APNIC Blog](https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/) — Chrome 探测性查询冲击根服务器的一手分析 4. [What is DNS / DNS cache poisoning / SAD DNS explained — Cloudflare Learning](https://www.cloudflare.com/learning/dns/what-is-dns/) — DNS 工作机制与投毒攻击防护 5. [Dependency Confusion — Alex Birsan](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) — 利用包仓库解析顺序的供应链攻击 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。