DNS 解析偶发超时排查：分层定位与抓包验证

线上偶发 `Temporary failure in name resolution`、抓包发现有的 DNS 请求 5 秒超时后重发才成功——这类”偶发解析慢”在 CentOS6+ 环境有典型根因。

一、根因：并行 A/AAAA 用同一源端口

CentOS6 以后解析器支持 IPv4/IPv6 并行查询，且用同一个 socket/源端口同时发 A（IPv4）和 AAAA（IPv6）记录请求。正常情况下两个响应都回来；但在有防火墙的网络里，”同源 IP、同目的 IP、同源/目的端口、同四层协议”的连接会被防火墙当成同一个会话，其中一个响应包（多为 AAAA）被当重复而丢弃。于是 socket 一直在等丢失的那个响应，导致解析超时、重发后才成功。

二、与老系统对比

RHEL5/CentOS5 等老系统是**串行**、且用不同随机源端口分别查 AAAA 和 A，不会被误并会话，虽效率低但不易踩这个坑。CentOS6+ 端口复用度更高、效率更好，却引入上述防火墙场景的问题。

三、定位与解决

用 dig +trace 域名 看是否偶发超时、tcpdump -i any port 53 抓包确认是否有请求无响应。解决方向：让解析不用并行同端口（如配置 options single-request-reopen / single-request），或调整防火墙/安全策略放行同端口不同记录的响应。若域名不支持 IPv6 却仍查 AAAA，也可从源头减少无效查询。

三、超时排查步骤清单

• 分层定位 → 本地 hosts/解析器 → 递归服务器 → 权威服务器，逐段测。
• 常见因 → 并发 A/AAAA 同源端口被防火墙误并会话、上游超时、EDNS 报文超 MTU 被丢。
• 验证 → 换公共 DNS 对比、tcpdump 抓 53 端口看是否收到响应。

偶发超时最容易被”重试就好”掩盖；抓包看请求是否真出去、响应是否真回来，比猜快得多。