一篇读懂 DNS：从输入域名到拿到 IP 的完整旅程

为什么需要 DNS：名字比 IP 好记，且 IP 会变

IP 地址（如 142.250.71.14）是机器的语言，域名（google.com）是人类的名字——DNS（Domain Name System）负责翻译。但 DNS 存在的更深理由是解耦：服务可以换 IP（迁移、扩容、多机房）而名字不变；一个名字可以对应多个 IP（负载均衡）；IP 不够好记且 IPv4 地址是稀缺资源。DNS 本质上是全球最大的分布式数据库：没有一台机器存着全部记录，数据按层级切分、层层委托，靠缓存撑起每秒数亿次的查询。

层级结构：从根到权威的四层委托

域名的结构从右往左分层：www.example.com 里 com 是顶级域、example 是二级域、www 是子域。对应的 DNS 服务器也是层级：根服务器（全球 13 组逻辑根，负责告诉你去哪找 .com）→ 顶级域服务器（.com/.cn/.org，负责告诉你 example.com 的权威在哪）→ 权威服务器（真正存着 example.com 的记录，你设置的解析服务就是它）→ 最后拿到 www 的记录。「权威」的含义：只有它给的答案是「正式的」，其他所有人都只是「带缓存的转述者」。

递归与迭代：一次查询的完整旅程

你在浏览器输入 www.example.com 后发生的事。第一步：本机缓存与 hosts——操作系统缓存、浏览器缓存、hosts 文件（手工优先级最高的静态映射）依次检查。第二步：问递归解析器——通常是你网络运营商的 DNS 或公共 DNS（8.8.8.8、1.1.1.1、223.5.5.5）。递归解析器是「跑腿的」：它替你走完整个查询链（先问根、根指路 .com、再问 .com、被指到权威、最后问权威拿到答案），把结果返回给你并缓存一份。第三步：逐层迭代——解析器与各级服务器之间是「迭代查询」（你告诉我下一步找谁），它与你之间是「递归查询」（你等着，我全权代办）。

flowchart LR
    A["浏览器"] -->|"① 查 www.example.com"| R["递归解析器<br>（运营商 / 8.8.8.8）"]
    R -->|"② 有缓存？直接返回"| R
    R -->|"③ 问根"| ROOT["根服务器<br>→ 去 .com"]
    R -->|"④ 问 TLD"| TLD[".com 服务器<br>→ 去 example 的权威"]
    R -->|"⑤ 问权威"| AUTH["权威 DNS<br>→ 142.250.71.14"]
    AUTH --> R
    R -->|"⑥ 返回 + 缓存"| A

TTL（Time To Live）决定缓存存活时间：权威记录里每条记录带 TTL（如 300 秒），所有中间缓存在 TTL 内直接复用。这就是「改了解析要等生效」的原因——旧记录在全网各级缓存里活到 TTL 过期；反过来，把 TTL 提前调小再迁移，是「无缝切流」的标准手法。

记录类型：A、CNAME、MX 与它们的产品含义

DNS 的记录不止「域名 → IP」。A / AAAA：域名 → IPv4 / IPv6 地址（最基本）。CNAME：别名——blog.example.com 的 CNAME 指向 example.github.io，解析时再跳一次；CNAME 后面不能再挂别的记录（域名「顶替」），所以裸域（example.com）配 CDN 常要用特殊手段。MX：邮件交换——告诉发信方「发给 @example.com 的邮件找哪台服务器」（邮件系统全靠它）。TXT：任意文本——现代的「证明域名所有权」（各家平台的验证）、SPF/DKIM（防邮件伪造）全靠 TXT。NS：指定权威服务器——换 DNS 服务商就是改这条。SRV/PTR 等小众类型各司其职。做业务的常见链路：域名 A 记录指向接入层 → 接入层 CNAME 到 CDN → CDN 回源到真实服务——每一跳都是一条 DNS 记录的设计决策。

安全与排障：劫持、污染与「DNS 慢」

DNS 劫持与污染：DNS 走 UDP 明文（53 端口），链路上的任何节点都可以篡改应答——运营商劫持（弹广告）、GFW 污染（返回假 IP）都发生在这一层。对策按彻底程度：DoH/DoT（DNS over HTTPS/TLS，加密且绕过中间劫持）、可信公共 DNS、以及企业场景的自建递归。「网站慢，是不是 DNS 慢」的排查：dig www.example.com 看查询耗时（Query time 与各段 answer）、对比不同解析器（本地运营商 vs 公共 DNS）的结果与速度、dig +trace 完整重放逐层查询——DNS 的问题特征是「TCP 连接都建立不起来」（IP 都没拿到）或「拿到的是错 IP」，而「连上了但慢」通常不是 DNS 的锅。CDN 的本质也是 DNS：同一个域名对不同地区的解析者返回不同的边缘节点 IP——DNS 的「按解析者地理位置应答」能力，是全球内容分发的地基。

DNS 的进阶话题：递归的选择、TTL 策略与故障案例

DNS 的进阶话题围绕三个运维决策展开。决策一：用谁的递归解析器。运营商默认 DNS 的优点近、缺点杂（劫持与污染的历史问题）；公共 DNS（8.8.8.8/1.1.1.1/223.5.5.5）稳定但有时远——解析延迟直接影响「所有网站的首次访问」（每个新域名都要多一次查询）。企业级的选择是自建递归（内网缓存 + 上游加密），兼顾延迟与可控。决策二：TTL 怎么定。TTL 的权衡：短 TTL（60s）迁移灵活但缓存失效、查询压力大；长 TTL（86400s）稳但切换慢。策略是分场景：稳定服务长 TTL、计划中的迁移提前降到短 TTL、配好 CDN 后的 CNAME 由厂商定。「改 DNS 的标准动作」是预案工程：提前 24–48 小时把 TTL 降下来 → 改记录 → 观察 → 恢复 TTL——没有预案的 DNS 切换，等于把「全网生效时间」交给运气。决策三：故障案例的形态学。案例一：权威 DNS 故障（厂商宕机）——全网解析失效，站点「看起来挂了」但服务本身正常（大厂因此做双权威服务商冗余）；案例二：TTL=0 的调试遗留（上线忘了调回，解析压力与生效延迟双输）；案例三：CNAME 链过长（每一跳都加延迟与失败点，规范是不超过两跳）。三个案例的共同教训：DNS 是「底层慢变量」——它坏的时候一切都坏，所以它的冗余、TTL 与预案要在出事前就位。

DNS 记录的实操设计：一个产品的完整解析方案

把 DNS 记录类型（正文）组合成一个产品的完整解析方案，设计决策立刻具体。场景：一个 SaaS 产品，主站 + API + 后台 + 文档 + 邮件。方案分解。example.com（裸域）：A 记录指向入口（或 ALIAS/ANAME 到 CDN——很多 DNS 服务商对裸域 CNAME 的限制有变通方案）。www：CNAME 到 CDN（CDN 再回源）。api：独立 A 记录或 CNAME 到 API 网关（API 与主站分离流量，故障与扩容互不影响）。admin：加 IP 白名单（DNS 不做安全，但解析到内网 LB + 应用层认证是常规组合——DNS 记录的「隐藏」不是安全，obscurity 不是防线）。docs：CNAME 到文档托管。MX 与 SPF：邮件服务商的记录组合（MX 指向邮件服务、TXT 写 SPF/DKIM/DMARC 防伪造——不配 DMARC 的域名，别人可以冒充你的域名发信）。验证用的 TXT：各家平台（搜索控制台、证书 CA、SaaS 集成）的域名验证。这个方案的元教训：DNS 记录是「产品架构在名字空间的投影」——每一个子域、每一条记录背后都是一个部署与流量的决策；DNS 设计做好了，后续的 CDN、证书、灾备切换都有了清晰的抓手。

DNS 的现代演化：DoH、DNSSEC 与「DNS 作为控制面」

DNS 的现代演化有三个方向，都值得认识。方向一：加密化（DoH/DoT/DoQ）。DNS 查询从明文 UDP 迁移到加密通道（HTTPS/TLS/QUoS 上的 DNS）——对抗劫持与窃听，浏览器（Firefox/Chrome 默认 DoH）与移动 OS 逐步默认化；伴生的新争论：加密让企业网络的 DNS 管控（过滤、审计）变难——「隐私 vs 管控」的博弈在 DNS 层重演。方向二：DNSSEC（数据签名）。给 DNS 记录本身加数字签名（区域逐级签名形成信任链）——解决「应答被伪造」的问题（DoH 解决的是「传输被窃听」，DNSSEC 解决「数据本身可信」）；现实是部署率不高（配置复杂、运维事故风险大——签了名但密钥管理出错的域名会「解析彻底挂掉」），大域名的选择性采用。方向三：DNS 作为控制面。DNS 的「全球可达 + 分层缓存」特性被复用为控制通道：CDN 调度（按解析者回不同 IP）、故障切换（健康检查驱动 DNS 切换——failover 的最简单实现）、灰度发布（按地区解析到新版本）、甚至内容分发的前置信号。演化的元视角：DNS 从「名字翻译」长成了「互联网的低成本全球广播控制面」——它古老、慢、却无处不在；理解 DNS 的现代角色，就是理解互联网「基础设施复用」的经典样本。

DNS 的进阶话题：递归的选择、TTL 策略与故障案例

DNS 的进阶话题围绕三个运维决策展开。决策一：用谁的递归解析器。运营商默认 DNS 的优点近、缺点杂（劫持与污染的历史问题）；公共 DNS（8.8.8.8/1.1.1.1/223.5.5.5）稳定但有时远——解析延迟直接影响「所有网站的首次访问」（每个新域名都要多一次查询）。企业级的选择是自建递归（内网缓存 + 上游加密），兼顾延迟与可控。决策二：TTL 怎么定。TTL 的权衡：短 TTL（60s）迁移灵活但缓存失效、查询压力大；长 TTL（86400s）稳但切换慢。策略是分场景：稳定服务长 TTL、计划中的迁移提前降到短 TTL、配好 CDN 后的 CNAME 由厂商定。「改 DNS 的标准动作」是预案工程：提前 24–48 小时把 TTL 降下来 → 改记录 → 观察 → 恢复 TTL——没有预案的 DNS 切换，等于把「全网生效时间」交给运气。决策三：故障案例的形态学。案例一：权威 DNS 故障（厂商宕机）——全网解析失效，站点「看起来挂了」但服务本身正常（大厂因此做双权威服务商冗余）；案例二：TTL=0 的调试遗留（上线忘了调回，解析压力与生效延迟双输）；案例三：CNAME 链过长（每一跳都加延迟与失败点，规范是不超过两跳）。三个案例的共同教训：DNS 是「底层慢变量」——它坏的时候一切都坏，所以它的冗余、TTL 与预案要在出事前就位。

小结

DNS 是分层委托的全球分布式数据库：根 → 顶级域 → 权威逐层指路，递归解析器替用户跑腿，TTL 控制缓存生命周期（改解析的生效延迟与 TTL 直接相关）。记录类型各有产品含义：A/AAAA 翻译地址、CNAME 做别名、MX 管邮件、TXT 做验证。安全上 DNS 明文 UDP 是劫持与污染的温床，DoH/DoT 是现代对策；排查用 dig 的 query time 与 +trace，但记住「连不上才查 DNS，连上了慢不是它的锅」。每次上网的第一跳都是这套系统在毫秒间完成的层层委托——互联网最古老也最成功的分布式设计。