03 · DNS 原理与排查
输入域名按下回车，第一件事不是发请求，而是查 DNS。域名解析慢、解析到旧 IP、某些地方能访问某些地方不能，都是 DNS 的典型问题。本篇讲清解析链路、缓存与 TTL，再给一套排查套路。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 从域名到 IP 的解析链路与排障 |
| 核心内容 | 递归/迭代查询、各级缓存、TTL、常见失败定位 |
| 读完能回答 | 为什么改完解析不生效？为什么本地能访问线上不行？ |
| 相关板块 | N04 HTTP ｜ N10 CDN 与负载均衡 |
一、解析链路：一次"地址簿"查询
text
浏览器 → 系统缓存 → 本地 DNS（递归） → 根 → 顶级域 → 权威 DNS → 拿到 IP| 环节 | 角色 |
|---|---|
| 本地缓存 / hosts | 最快，但可能过期或被人改 |
| 递归解析器 | 替你逐级查询并缓存结果（运营商 / 公共 DNS） |
| 根 / 顶级域服务器 | 只管"告诉你去哪一级问" |
| 权威 DNS | 域名真实记录的所有者 |
心智模型：DNS 像"按目录查电话"，每一级只告诉你下一级在哪，最后才返回真实 IP。
二、记录类型
| 类型 | 含义 |
|---|---|
| A / AAAA | 域名 → IPv4 / IPv6 |
| CNAME | 域名 → 另一个域名（别名） |
| MX | 邮件服务器 |
| TXT | 文本记录（SPF、验证等） |
| NS | 指定权威服务器 |
三、TTL 与缓存：为什么"改了不生效"
| 概念 | 说明 |
|---|---|
| TTL | 记录可被缓存的秒数 |
| 改 TTL 时机 | 变更前先调小 TTL，变更完再调回 |
| 缓存层级 | 浏览器 / 系统 / 递归解析器各有一层 |
改解析不生效，八成是 TTL 未到。排障前先确认"你查到的 IP 是旧值还是新值"，再决定是否等待或清缓存。
四、常见失败定位
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
ERR_NAME_NOT_RESOLVED | 域名拼错 / 记录不存在 | nslookup 确认 |
| 本地通、线上不通 | hosts 或本地缓存覆盖 | 对比公共 DNS 结果 |
| 解析到旧 IP | TTL 未过 / CDN 切换中 | 等 TTL 或换解析器 |
| 时快时慢 | 递归解析器距离远 / 有故障 | 换公共 DNS 对比 |
| 解析成功但连不上 | 域名没问题，是连通性 | 转到 N11 抓包 |
五、自检清单
- [ ] 能画出递归查询到权威服务器的链路
- [ ] 知道 A/CNAME/MX/NS 记录各是什么
- [ ] 能解释"改了不生效"与 TTL 的关系
- [ ] 会用手头的
nslookup/dig查看解析结果 - [ ] 能把 DNS 问题与连通性问题区分开
六、常见误区
| 误区 | 事实 |
|---|---|
| "改解析立即生效" | 要等所有缓存层的 TTL 过期 |
| "DNS 慢就是解析器问题" | 也可能是多个 A 记录之一失效 |
| "CDN 只解决静态缓存" | CDN 也做 DNS 智能调度（见 N10） |
| "清了浏览器缓存就够" | 系统与递归解析器也有缓存 |
七、动手练习
练习 A：看当前解析
nslookup github.com（Windows）或 dig +trace github.com（Linux/macOS），观察返回的 IP 与 TTL。
练习 B：对比解析器
分别用运营商 DNS 与 1.1.1.1 解析同一个域名，对比结果差异与耗时，思考差异来源。
练习 C：走完整链路
dig +trace 观察根 → 顶级域 → 权威的每一跳，把输出与第一篇的链路图对上。
相关文档
本区
- 04 · HTTP 与 HTTPS 深入 —— 解析之后才发生的请求
- 10 · CDN 与负载均衡 —— DNS 调度是 CDN 的关键一环
- 11 · 抓包与网络调试 —— DNS 之后的连接排障