3. DNS解析排查：nslookup/dig命令使用、DNS缓存问题、DNS服务器负载、域名解析劫持
连接超时，很多时候不是网络不通，而是域名没找到路。我处理过的故障里，大概有三分之一跟DNS有关。你想想看，客户端连不上服务器，第一反应是ping，但ping不通就一定是网络问题吗？不一定。域名解析这一步卡住了，后面全是白费功夫。
这一章，咱们就把DNS排查的四个核心点掰开揉碎。我会把我在一线用的命令、踩过的坑、总结的套路，全摆出来。
3.1 基础排查：nslookup 和 dig
先说最常用的两个工具。nslookup简单，dig详细。我个人习惯，快速验证用nslookup，深挖问题用dig。
3.1.1 nslookup 快速验证
nslookup是Windows和Linux都自带的。用法很简单：
nslookup www.example.com输出会显示域名对应的IP地址。如果返回“Non-existent domain”或者超时，那问题就出在DNS解析上。
但nslookup有个坑——它默认走系统配置的DNS服务器。如果你想指定一个DNS服务器来测试，比如用Google的8.8.8.8：
nslookup www.example.com 8.8.8.8我在项目中遇到过，客户说网站打不开，nslookup返回了IP，但就是连不上。后来发现，nslookup返回的是旧IP，CDN节点已经切换了。所以，光看有没有返回IP还不够，还得看IP对不对。
3.1.2 dig 深度诊断
dig是Linux下的王牌工具。信息量比nslookup大得多。我排查DNS问题时，90%的时间在用dig。
基本用法：
dig www.example.com输出里，我最关注这几个字段：
| 字段 | 含义 | 排查要点 |
|---|---|---|
| QUESTION SECTION | 你问了什么域名 | 确认域名没写错 |
| ANSWER SECTION | DNS返回的IP地址 | 检查IP是否预期 |
| AUTHORITY SECTION | 权威DNS服务器 | 确认解析链路是否完整 |
| Query time | 解析耗时 | 超过100ms就要警惕 |
| MSG SIZE | 响应包大小 | 超过512字节可能被截断 |
举个例子，我想看完整的解析过程：
dig +trace www.example.com这个命令会从根DNS服务器开始，一步步追踪到权威服务器。我曾经用这个命令发现，某个域名的权威服务器响应极慢，导致每次解析都要等5秒。这就是连接超时的真凶。
3.2 DNS缓存问题
DNS缓存是双刃剑。它能加速解析，也能让你排查时一头雾水。
3.2.1 本地缓存
操作系统、浏览器、本地DNS服务（如systemd-resolved）都会缓存。我遇到过最典型的场景：
开发说“我改了DNS记录，但客户端还是连到旧IP”。我一查，客户端的本地缓存没刷新。
清理本地缓存的命令：
- Windows：
ipconfig /flushdns - Linux（systemd-resolved）：
systemd-resolve --flush-caches - macOS：
sudo killall -HUP mDNSResponder
清完缓存再试，问题往往就解决了。但要注意，这只是临时手段。根本原因可能是TTL设置不合理。
3.2.2 递归DNS服务器缓存
运营商或公共DNS（如114.114.114.114）也有缓存。你清了自己的缓存没用，得等它们的缓存过期。
怎么判断是递归DNS缓存问题？用dig指定不同的DNS服务器：
dig @8.8.8.8 www.example.com
dig @114.114.114.114 www.example.com如果两个返回的IP不一样，那很可能其中一个的缓存没更新。我记得有一次，某省用户反馈无法访问我们的服务，但其他省正常。一查，是当地运营商DNS缓存了一个错误的CNAME记录。
3.3 DNS服务器负载
DNS服务器也是服务器，扛不住压力一样会挂。我见过不少案例，业务高峰期DNS响应变慢，导致大量连接超时。
3.3.1 如何判断DNS服务器过载
几个典型信号：
- 查询耗时飙升： 正常10ms，现在500ms以上
- 丢包率上升： 部分查询直接无响应
- SERVFAIL： 服务器返回临时故障
用dig可以看查询耗时：
dig @your-dns-server www.example.com看输出里的“Query time”。如果连续多次都超过200ms，那服务器负载可能有问题。
3.3.2 负载均衡与冗余
生产环境，DNS服务器一定要做冗余。我建议至少部署两台，用不同的IP。客户端配置时，主备DNS都写上。
举个例子，某公司只配了一台DNS服务器，结果服务器宕机，全公司无法上网。后来他们加了第二台，用Keepalived做高可用，再没出过类似问题。
| 部署方式 | 优点 | 缺点 |
|---|---|---|
| 单台DNS | 配置简单 | 单点故障，负载高时影响大 |
| 主备DNS | 高可用，故障自动切换 | 需要额外配置同步机制 |
| 多活DNS | 负载分担，响应更快 | 架构复杂，需要全局负载均衡 |
3.4 域名解析劫持
这是最头疼的问题。域名解析劫持，说白了就是你访问A网站，DNS却把你带到了B网站。可能是运营商干的，也可能是中间人攻击。
3.4.1 如何发现劫持
几个排查方法：
- 对比不同DNS服务器： 用8.8.8.8和114.114.114.114分别解析，看IP是否一致
- 检查HTTP响应： 如果返回的页面内容异常，比如多了广告，那很可能被劫持了
- 使用DNSSEC： 如果域名配置了DNSSEC，劫持会被检测出来
我印象很深的一次，某电商网站用户反馈，支付页面跳转到了钓鱼网站。一查，是当地运营商在DNS层面做了劫持，把支付域名指向了恶意IP。
3.4.2 应对措施
对付劫持，我一般这么干：
- 改用加密DNS： 比如DNS over HTTPS（DoH）或DNS over TLS（DoT）。这样DNS查询内容不会被中间人篡改。
- 配置可信DNS服务器： 比如用8.8.8.8、1.1.1.1，或者企业内部自建的DNS。
- 启用DNSSEC： 从源头上防止伪造DNS响应。
3.5 知识体系总览
下面这张图，是我梳理的DNS排查知识体系。你可以把它当成排查时的路线图。
这张图把DNS排查分成了四个方向。你遇到连接超时，先别慌。按这个框架，一步步来：先用dig确认解析结果，再查缓存，然后看服务器负载，最后考虑劫持。大部分问题都能定位到。