6.1 DNS域名解析：出发前的问路

6.1 DNS域名解析：出发前的问路

本节摘要：DNS 是互联网的全球电话簿，用"根—顶级—权威"三级分层和遍布各地的缓存，把域名翻译成 IP。本节讲清递归与迭代查询的分工、完整解析链路、缓存与 TTL 的权衡、常见记录类型，并实测一次解析全过程。

旅程回到起点补一个前置问题：你在浏览器输入的是域名，数据包需要的却是 IP（第 4 章的门牌）。谁来翻译？为什么这套体系每天扛住万亿次查询而不崩溃？答案是一个没有中心服务器的全球分布式系统——DNS。

一、三层官僚体系加一个本地代理

域名空间是一棵倒着的树：根（.）下面分出顶级域（com、cn、org），再往下是各机构的权威域（example.com），再往下随意细分（www、mail 各是主机名）。每一级只知道自己这一层该问谁——这正是第 4 章"逐跳转发"思想在应用层的翻版。

参与翻译的角色分两类。递归服务器（你配置的那个 DNS 地址，如运营商的或公共 DNS）代理你完成整个打听过程；权威服务器是各级域的"户籍科"，只回答自己管辖的记录，且只给答案不给代办。

解析 www.example.com 的完整链路（本机缓存未命中时）：

本机 → 递归服务器：  "www.example.com 的地址？"（递归：你全权帮我办）
递归服务器检查自己的缓存（曾有记录且未过期 → 直接回答，流程终止）

缓存未命中，递归服务器开始迭代打听：
  ① 问根服务器："www.example.com？"
     根："我不认识，但 com 归这几位管"（返回 com 的 NS 记录）
  ② 问 com 顶级域服务器："www.example.com？"
     com："example.com 的权威服务器在这"（返回 NS + 地址）
  ③ 问 example.com 权威服务器："www.example.com？"
     权威："93.184.216.34，TTL 3600 秒"（最终答案）
递归服务器 → 本机：93.184.216.34（并缓存 3600 秒）

工程事实：全球 13 组根服务器 IP（借助任播扩展成上千个实例），
一次完整解析通常 20~80ms；命中缓存则 1ms 级。
你 99% 的查询根本走不到根——本地或运营商缓存已解决。
​

图：一次解析的问路链

二、缓存与 TTL：一致性与速度的跷跷板

每条 DNS 记录都带 TTL（生存时间），缓存者在 TTL 内可以不再打听。TTL 是站长做的权衡：设 3600 秒，全球解析压力小、用户访问快，但服务器换 IP 后最长一小时内有用户访问旧地址；设 60 秒，切换几乎即时，但查询量大增。计划迁移的正规做法是提前把 TTL 调小，切换后再调回。

常见记录类型备查：A（域名到 IPv4）、AAAA（到 IPv6）、CNAME（域名到域名的别名）、MX（收信服务器）、NS（该域由谁权威解析）、TXT（任意文本，SPF 反垃圾邮件与域名验证在用）。

三、实测：看清你自己的解析链

# 1. 本机看到的解析结果与缓存
$ nslookup www.example.com
Server:   192.168.1.1        ← 当前递归服务器（网关）
Address:  192.168.1.1#53
Non-authoritative answer:     ← "非权威"：答案来自缓存而非户籍科
Name: www.example.com
Address: 93.184.216.34

# 2. 追踪每一级（模拟递归服务器的迭代过程）
$ dig +trace www.example.com
.               NS  a.root-servers.net.        ← 先拿到根
com.            NS  a.gtld-servers.net.        ← 根指路 com
example.com.    NS  a.iana-servers.net.        ← com 指路权威
www.example.com A   93.184.216.34              ← 权威给最终答案

# 3. 查响应耗时与缓存情况
$ dig www.example.com | grep "Query time"
;; Query time: 1 msec      ← 缓存命中的典型值

解读：换个冷门域名再测，耗时会跳到几十毫秒——
那是真正走了迭代链。公共 DNS（如 114 或 1.1.1.1 一类）
与运营商 DNS 的差别主要在缓存命中率与出境路径，
"换个 DNS 网速变快"多半是把解析耗时从 80ms 降到 1ms，
对后续传输速度本身并无魔法加成。
​

四、案例：一次"半个办公室打不开某网站"

背景：部分员工反映某内部系统打不开，另一部分正常。该系统前一天做过服务器迁移。

排查：
$ dig internal.corp.example @公司递归
→ 返回旧 IP 10.2.5.31（TTL 显示还剩 1400 秒）

解读：迁移后旧记录 TTL 未清。不同办公室走的递归服务器不同，
各自缓存了新旧不同的记录——"薛定谔的故障"。
且本机/浏览器还有第二层缓存，即使递归已更新，
旧客户端仍在用内存里的旧答案。

处置：临时把旧服务器 IP 挂在负载均衡上兜底，
等最长 TTL 自然过期（40 分钟）；后续流程改进——
迁移前 24 小时先把 TTL 降到 60 秒，切换瞬时生效，
稳定后再调回。本机层让用户刷新 DNS 缓存或重启浏览器。

变式：CDN 的智能解析就是故意利用这个体系——
同一域名，电信用户问电信本地递归，得到电信机房 IP；
联通用户得到联通机房 IP。DNS 不只是电话簿，
还是全球流量调度器的第一级。
​

⚠️ 常见坑：DNS 走的是 UDP 53（5.1 节），公网上存在伪造应答的可能——应答早于真答案到达即被采信，这就是 DNS 缓存投毒的入口。现代防线是随机化事务 ID 加端口、以及 DNSSEC 签名链（第 7 章再议）。

常见疑问

hosts 文件和 DNS 什么关系？ hosts 是本机静态映射表，优先级在 DNS 查询之前——测试环境"把域名指向内网机器"最常用的手法就是改 hosts。它也常被恶意软件利用劫持域名，排查"只有某台机器解析异常"时记得先看它。

为什么换公共 DNS 有时能"解锁"访问？ 部分解析策略按递归服务器来源返回不同结果（分区解析），换递归等于换了"问路人"，可能得到更优或不同的目标地址——这不是魔法加速，是调度体系被你换了一条入口。

本节要点回顾

• 三级分层：根、顶级、权威各管一段，没有谁掌握全库——可扩展性的来源
• 递归与迭代：递归服务器代办全程，权威只答不办
• 缓存链：本机、浏览器、递归层层缓存，TTL 决定一致性上限
• TTL 权衡：迁移前调小是运维常识，事后补课要等最长一个 TTL
• 调度价值：CDN 靠分区解析做第一级流量调度

问路完毕，下一节正式开读网页对话的语法书——HTTP 从 1 到 3。