服务器网关切换后域名解析故障排查实录

一、故障现象：IP能通，域名却“失踪”了？

上周在维护测试环境时遇到一个诡异的网络问题：某服务器（主机A）出现能ping通外网IP（如8.8.8.8），但无法ping通域名 的异常现象。其他配置未变更，仅网关从172.19.0.150改为172.19.0.179。这种“能通IP不通域名”的症状，直觉指向DNS解析链路异常，但具体问题点需要一步步拆解。

毫无疑问，这个问题肯定是 DNS 的问题，但是 DNS 哪出了问题，却非常诡异。

二、初步排查：定位DNS解析的“断链点”

0. 更换网关，DNS解析正常

更换另一个网关，网络恢复正常了，说明是网关的问题，那么问题就来了，一般来说 DNS 解析是跟网关没有关系的，网关有问题的话应该 Ping 不通 IP，只更换网关恢复正常说明 DNS 配置又没问题，这就是诡异的点：网关跟DNS到底有什么关系。

ChatGPT这么说：

1. DNS配置验证：先看基础设置

查看当前DNS服务器
```
bash
cat /etc/resolv.conf  
# 输出nameserver 8.8.8.8（已手动设置公共DNS）
```
✅ 确认主机已正确配置DNS服务器（8.8.8.8），但问题依旧存在，说明配置无错，需排查网络通路。

2. 路由与连通性测试：ping与traceroute的双重验证

测试DNS服务器连通性
```
bash
ping 8.8.8.8  # 通！说明ICMP协议可达
traceroute 8.8.8.8  # 路由路径正常，无明显丢包
```
✅ 物理链路和基础路由正常，但域名解析仍失败，问题聚焦到DNS协议层面。

3. DNS解析实测：用工具撕开“表象”

手动触发解析请求
```
bash
nslookup baidu.com  # 超时无响应
dig baidu.com  # 同样卡住，无返回结果
```
❌ 直接证据：DNS查询未成功获取响应，说明请求可能未送达或被拦截。

三、深度诊断：抓包工具揭露“协议级封锁”

1. tcpdump抓包：监控DNS流量细节

执行抓包命令后再次发起解析请求：

bash
sudo tcpdump -i enp2s0f0 port 53 -n

关键输出分析：

UDP请求：主机向8.8.8.8发送了UDP 53端口的A记录查询（A? baidu.com），但无任何响应包。
TCP请求：尝试使用TCP协议重新查询（dig +tcp baidu.com），抓包显示三次握手成功，且DNS服务器返回了解析结果（包含baidu.com的IP地址）。

🔍 核心结论：

UDP 53端口的DNS请求被网关或链路设备拦截，导致解析失败；
TCP 53端口未受限制，说明问题出在协议级过滤（常见于防火墙对UDP DNS的封锁）。

四、网关特性分析：iKuai路由器的“特殊规则”

由于故障网关为iKuai（爱快）路由器，结合其功能特性进一步排查：

1. 防火墙策略检查

登录iKuai管理后台（http://172.19.0.179），进入 安全设置 > 防火墙规则，发现一条针对UDP协议、目标端口53的出站拦截规则。该规则默认阻断内网主机通过UDP协议访问外部DNS服务器，以防止DNS放大攻击，但误判导致正常解析请求被拦截。

2. 规则调整与验证

修改规则：将拦截动作改为“允许”，并指定目标端口为53（UDP）。
重启网络服务：确保规则生效。

复测解析：

bash
dig baidu.com  # 秒级返回解析结果，问题解决！

五、技术总结：从现象到本质的排查逻辑

1. 故障链还原

网关切换 → 触发UDP 53端口拦截规则 → DNS查询请求（UDP）无法回包 → 域名解析失败。关键点：UDP与TCP协议的差异化处理——多数防火墙默认允许TCP 80/443等常用端口，但可能对UDP协议实施更严格的策略。

2. 通用排查方法论

分层验证：按“物理层→网络层→传输层→应用层”顺序排查，先确认IP连通性，再聚焦协议细节。
工具优先：善用ping/traceroute/dig/tcpdump等工具，通过抓包获取原始流量数据，避免主观臆断。
设备特性适配：不同厂商的网络设备（如iKuai、华为、Cisco）可能有默认安全策略，需结合官方文档分析规则逻辑。

六、延伸思考：DNS解析的“攻防博弈”

当前网络环境中，DNS常成为安全策略的“敏感点”：

运营商层面：部分ISP会拦截非官方DNS请求，强制使用自有解析服务；
企业防火墙：为防范数据泄露，可能限制UDP 53端口，仅允许通过HTTP(S)/TLS加密通道传输DNS数据（如DoH/DoT）。

应对建议：

若遇UDP封锁，可临时使用TCP解析（dig +tcp）或部署DNS加密工具（如cloudflared）；
长期方案需与网络管理员协同，在安全策略与业务需求间找到平衡点。

结语

这次故障排查看似围绕“DNS解析”，实则涉及网络协议特性、设备策略配置、安全规则适配等多个技术维度。作为运维人员，保持“用数据说话”的习惯（如抓包分析），比依赖经验判断更能快速定位问题。下次遇到类似“能通IP不通服务”的场景，不妨从协议层开始抽丝剥茧，往往能柳暗花明。

目录