「域名打不开」可能是 DNS 的问题，也可能不是。要快速判断，得先搞清楚一次域名解析到底经过了哪些环节，以及每个环节用什么工具验证。
解析链路的完整顺序
应用发起解析（如 curl 访问 example.com）时，典型的查找顺序：
- 浏览器/应用自身缓存：Chrome 在
chrome://net-internals/#dns可查看。 - 本机 hosts 文件：
/etc/hosts，优先级最高。 - 系统缓存与本地解析器：Linux 桌面常见 systemd-resolved（监听 127.0.0.53）；服务器上也可能直接读
/etc/resolv.conf里配置的 DNS。 - 递归解析器：如运营商 DNS、
223.5.5.5（阿里）、119.29.29.29（腾讯）、8.8.8.8（Google）。它代替客户端完成剩下的全部工作。
递归解析器手上没有答案时，执行迭代查询：问根服务器（.）→ 得到 .com 顶级域服务器地址 → 问顶级域 → 得到 example.com 权威服务器地址 → 问权威 → 拿到 A 记录。结果按 TTL 缓存后返回给客户端。
递归 vs 迭代一句话区分：递归是「你给我最终答案」（客户端↔解析器），迭代是「你告诉我下一步问谁」（解析器↔各级服务器）。
dig：逐段验证每一环
dig（bind-utils / dnsutils 包）是 DNS 排障的标准工具。基础用法：
dig example.com # 用系统默认解析器查 A 记录dig example.com A +short # 只要答案：IPdig example.com AAAA +short # IPv6dig example.com MX # 邮件记录dig example.com NS # 权威服务器dig @223.5.5.5 example.com # 指定解析器，绕开本机配置dig -x 93.184.216.34 # 反解 PTR输出里先看三个位置：
status: NOERROR：查询成功；NXDOMAIN表示域名不存在；SERVFAIL通常是解析器或权威故障。ANSWER SECTION：真正的答案和 TTL。SERVER: 127.0.0.53#53：这次是谁回答的——判断是否命中本地缓存的关键。
逐跳追踪：dig example.com +trace 从根开始把迭代过程完整走一遍，可以定位「到底是哪一级给的答案不对」。
四种典型故障的定位套路
1. 别人能打开，我这台机器打不开。 先 dig example.com 对比 dig @223.5.5.5 example.com。默认解析器答案错、公共解析器答案对 → 本机 DNS 配置或运营商劫持问题，检查 /etc/resolv.conf。两者都错 → 域名本身的问题。
2. 刚改了 DNS 记录，有的生效有的不生效。 TTL 缓存所致。dig example.com 看 ANSWER 里的 TTL 秒数和 SERVER 是谁——不同递归解析器缓存过期时间不同，全球生效需要等到旧记录 TTL 全部到期。变更前把 TTL 临时调低（如 300 秒）是标准操作。
3. 域名能解析，但 IP 不对。 检查 /etc/hosts 是否有人写过静态映射；再确认查的记录类型对不对——把 AAAA 当 A 看会以为「解析异常」。
4. 内网域名解析失败。 内网域名通常只存在于内网 DNS。dig @内网DNS地址 域名 能通而默认不行，说明 /etc/resolv.conf 没指向内网 DNS，或 systemd-resolved 的分流规则没配对。
记录类型最小知识
| 类型 | 作用 | 注意点 |
|---|---|---|
| A / AAAA | 域名 → IPv4 / IPv6 | 一个域名可有多条，客户端轮询 |
| CNAME | 域名 → 另一个域名 | 不能与其他记录共存在同名节点；根域名（如 example.com）按标准不应使用 CNAME |
| MX | 邮件投递目标 | 指向域名，优先级数字越小越优先 |
| TXT | 任意文本 | SPF 反垃圾、域名所有权验证都靠它 |
| NS | 指定该域的权威服务器 | 改 NS 等于把整个域的解析权移交 |
| PTR | IP → 域名（反解） | 邮件服务器常校验，普通网站可不管 |
小结
DNS 排障的核心动作只有三个：对比不同解析器的答案（dig @）、看状态码和 TTL、必要时 +trace 走全程。先确认「解析出来的 IP 对不对」，再去怀疑网络和服务器——顺序反了会浪费大量时间。
延伸阅读
分享文章
生成精美分享图或复制链接，与更多人分享本文。
继续阅读
最后更新于 ，距今已过 32 天
部分内容可能已过时