DNS 解析细节：一次访问背后的接力链

域名到 IP 不是一次查询，是一条四层接力。搞懂每层缓存，才知道慢在哪、怎么救。

输入域名到页面开始加载之间，浏览器要先走一趟 DNS 接力。大多数性能文章把这一步一句带过，但真实排查里，DNS 往往是首屏慢的隐形元凶——尤其首次访问、跨运营商、海外域名时。

解析链路：从根到权威

以访问 www.example.com 为例，一次完整解析要穿过四层服务器：

1. 递归解析器（通常是运营商或公共 DNS，如 223.5.5.5、8.8.8.8）：替你跑完全程，把最终答案给你 2. 根 DNS 服务器：全球 13 组，回答「.com 去哪问」 3. 顶级域（.com）服务器：回答「example.com 的权威服务器在哪」 4. 权威 DNS 服务器：域名商或云解析提供，给出 www.example.com 的最终记录

递归器问根、根答 .com 位置；再问 .com、答权威位置；最后问权威拿到记录。全程三次往返，任何一环慢都拖慢首屏。

记录类型速查

• A：域名 → IPv4 地址，最常见

• AAAA：域名 → IPv6 地址

• CNAME：域名 → 另一个域名（别名），WWW 子域和 CDN 常用

• MX：邮件交换记录，决定邮件进哪个服务器

• TXT：文本记录，SPF/DKIM 反垃圾邮件和域名验证靠它

• NS：指定权威 DNS 服务器

CNAME 有个坑：CNAME 记录的域名不能再有其他记录（MX、TXT 都不行），所以裸域（example.com）通常不能直接用 CNAME，要用 A 或别名记录。

TTL：缓存与生效的博弈

每条 DNS 记录带一个 TTL（秒），告诉各环节缓存多久。TTL 是双刃剑：

• TTL 长（如 86400，一天）：解析快、服务器压力小，但改记录要一天才全球生效

• TTL 短（如 300，五分钟）：改记录五分钟内生效，但解析器频繁回源

迁移前的标准动作：提前一到两天把 TTL 降到 300，等旧 TTL 过期、全球缓存都变成短缓存后，再切新 IP——回滚同样在五分钟内完成。这就是「先降 TTL，再动记录」。

排查工具箱

三条命令覆盖 90% 的 DNS 排查：

# 看本地解析结果与所用解析器
nslookup example.com

# 看完整链路，加 trace 看逐级应答
dig example.com +trace

# 指定解析器对比，查运营商 DNS 是否缓存未过期或故障
dig @223.5.5.5 example.com
dig @8.8.8.8 example.com

常用判断：

• 本地解析错、公共 DNS 正确：运营商递归缓存没过期，换 DNS 或等 TTL

• +trace 卡在某一跳：那一层的 NS 记录配置有误

• A 记录存在但网站打不开：是网络层问题，不是 DNS——去看端口、防火墙、服务状态

DNS 与首屏性能

首次访问域名，DNS 解析是串行阻塞：解析完才能建立 TCP 连接。两个优化点：

• dns-prefetch：页面上有第三方域名（字体、统计、CDN）时提前解析：

<link rel="dns-prefetch" href="//fonts.gstatic.com">

• preconnect：不光解析，连 TCP+TLS 都提前握手，第三方资源收益明显：

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

只对确定会用的第三方域加，滥加会浪费连接资源。

换 DNS 服务商的注意事项

• 先在新的解析商建好全部记录（A、CNAME、MX、TXT 一个别漏），再改 NS——顺序反了邮件和验证全断

• 改完 NS 用 dig NS example.com +trace 确认根已指向新服务商

• 旧服务商的记录保留至少 48 小时，防个别递归器还在问旧权威

一句话总结：DNS 是「多层缓存 + 多级接力」的系统，改动前先降 TTL，排查时先分清本地、递归、权威哪一环出了问题。