DNS 解析故障：8 种场景、4 类病症与诊断处理方法

整个办公室都打不开内部网站，直接 ping IP 却一路畅通——十有八九，肇事者是 DNS 解析（DNS Resolution）。本文从一次实战实验（lab）出发，把 8 种 DNS 故障场景归纳为 4 类病症，并附上用 dig/nslookup 诊断的方法，以及企业网络的预防之道。

为什么 DNS 故障会让整个系统"瘫痪"？

DNS（Domain Name System，域名系统）把易记的域名转换成 IP 地址供计算机连接；几乎每一次连接——网页、邮件、内部应用——都始于一次 DNS 查询。DNS 出错时，症状五花八门："打不开网页""应用报连接错误"——支持团队很容易修错方向，而根源只不过是一条没被正确应答的查询。因此实战实验把 DNS 故障划分为各有体征的"病症组"，几秒钟就能锁定范围。

8 种场景，4 类病症

原实验把 8 个故障案例归入 4 组，分类依据是谁在"说谎"：服务器不应答、服务器答"没有数据"、服务器答错，还是客户端自己插了一脚。每个案例在运行 dig（Linux/macOS 上的标准 DNS 查询工具）时都有各自的体征。

病症组	故障场景	典型体征
1. 服务器不应答	超时（timeout）；服务器拒绝查询；上游（upstream，上级服务器）被阻断	dig 收不到应答，或收到拒绝/报错信息
2. 服务器答"没有"	NXDOMAIN——服务器答复该域名不存在	Status: NXDOMAIN
3. 服务器答错	迁移服务器后记录仍指向旧 IP	应答非常快、有 answer——但 IP 不对
4. 客户端插一脚	/etc/hosts 文件覆盖；客户端缓存（cache）留着旧 IP	dig 结果正确，但应用仍连错地址

第 1 组：服务器不应答

DNS 服务器保持沉默或拒绝服务。三种变体：超时（timeout）——查询包石沉大海（通常是防火墙所致或服务未运行）；被拒绝（refused）——服务器活着但不肯服务，常见于只允许特定网段查询的配置；上游被阻断——内部服务器问不了上级服务器（forwarder），于是所有公网域名全部报错。

第 2 组：服务器答"没有"——NXDOMAIN

服务器明确应答了，但内容是"不存在"（NXDOMAIN——non-existent domain，域名不存在）。成因：域名拼写错误、内部 zone 尚未创建记录，或者刚创建但还没同步传播（propagation）到应答的那台服务器。

第 3 组：服务器答错——记录指向旧 IP

最危险的一组，因为系统看起来一切正常：查询秒回、有 IP——但那是服务迁移到新服务器之后的旧 IP。于是有的用户进新版页面，有的进旧版页面，有的什么也进不去。

第 4 组：客户端插一脚——/etc/hosts 与本地缓存

哪怕 DNS 完全正确，客户端也可能自己"拆台"：/etc/hosts 文件（本地把域名映射为 IP 的文件，查询优先级高于 DNS）里残留旧记录；或操作系统/浏览器的 DNS 缓存（DNS cache）留着旧结果。IP 迁移之后尤其常见：技术员的机器看到的是新地址，用户的机器仍访问旧地址。

几秒内逐组定位

排查流程从 dig（Windows 上用 nslookup）应答中的体征切入：

1. 读 dig ten-mien.vn 的 status 行： - 等待超时无应答 → 第 1 组（timeout）：检查防火墙与 DNS 服务。 - status: REFUSED → 第 1 组（拒绝）：复查允许查询的配置（allow-recursion、ACL）。 - status: SERVFAIL → 第 1 组（上游）：服务器收到了查询但解析不动——检查 forwarder。 - status: NXDOMAIN → 第 2 组：核对域名拼写及对应的 zone/记录。 - status: NOERROR 且有 answer → 拿返回 IP 与服务实际 IP 对比，揪出第 3 组。
2. 在多台 DNS 服务器之间对比： 分别运行 dig @8.8.8.8 ten-mien.vn 和 dig @1.1.1.1 ten-mien.vn，再与内部 DNS 对账。各服务器结果不同 → 第 2–3 组，问题在服务器侧；结果一致但应用仍出错 → 第 4 组，问题在客户端。
3. 从 DNS 服务器检查上游： 直接查询权威域名服务器，确认源头数据仍然正确还是已经过期。
4. 检查客户端： 查看 /etc/hosts 文件，清空 DNS 缓存（Windows 用 ipconfig /flushdns，Linux 用 flush systemd-resolved/nscd，再清浏览器 DNS 缓存），然后重试。

记住实验的点睛之句："dig 跑得通，不代表 DNS 没错。" 第 3 组和第 4 组都能让 dig "跑得很好"——服务器秒答、有结果——但结果要么是错的，要么被应用无视，而这恰恰是最棘手的案例。

用 Docker Compose 和 dnsmasq 搭实验

最值得借鉴的一点：全部 8 个案例都用 Docker Compose（多容器编排工具）加上 dnsmasq 搭建——用真正的 DNS 服务器而非模拟环境。学习者必须亲手配置错误记录、亲手阻断上游、亲手改写 /etc/hosts……再用 dig 亲手诊断。这种"自己造病再自己治"的学习方式，理解深度远超读理论——是培训网络运维团队的优秀范本。

企业网络的预防之道

处理得再好也不如压根不发生；以下是企业 DNS 基础设施的几项标准措施：

• 至少运行两台相互独立的内部 DNS 服务器，一台出故障不至于让全部访问瘫痪。
• 为内部 DNS 配置备用 forwarder——主上游被阻断时，服务器自动切换到其他路径。
• 主动监测： 从网络中的多个位置定期探测关键域名；应答变慢或结果异常时尽早告警。
• IP 迁移前调低 TTL： 在切换阶段把记录的存活时间设短，让旧缓存尽快过期，稳定后再调回来。
• 集中管理 hosts 文件： 不要在终端机器上手工改 /etc/hosts；一切自定义映射都收进内部 DNS，当作正式配置来管理。
• 标准化运维： 把 DNS 故障处置流程按上述 4 类病症文档化，让值班技术员哪怕半夜也能立刻处置。

什么时候需要专职 IT 支持团队？

对于缺乏资深网络人员的企业，DNS 故障属于最耗时的排查类事故：症状蔓延到所有应用，但没有任何应用真的坏了。Wotech 提供企业 IT 与网络基础设施支持服务——内部 DNS 设计与运维、基础设施监测、按流程处置事故——让你不必亲自给这些难诊难断的网络病"当医生"。

结论

8 种 DNS 故障场景收拢为 4 类病症——服务器不应答、服务器答"没有"、服务器答错、客户端插一脚——每类在 dig 下各有体征。掌握了这张表，技术团队就能从瞎猜转向系统性定位：读 status、比对服务器、查上游、再到客户端。从运维角度看，DNS 的冗余与监测，永远比全公司"断网"一天便宜。

资料来源：整理自 Facebook 技术分享，由 Wotech Electronics 编辑。

您的企业正遇到疑似 DNS 的网络故障，或想规范化内部网络基础设施？联系 Wotech，获取勘测、监测与专业技术支持。