这个坑值得记一笔。Ubuntu 22.04 上用 nslookup api.example.com 秒回，同样的域名 dig 要等五秒才超时，应用侧解析失败率在监控里到了 3%，resolv.conf 里前后配了两个内网 DNS。
刚开始盯着「systemd-resolved 占了 127.0.0.53，dig 直连时行为和 nslookup 不一致」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。第一个 nameserver 不可达，dig 要等满 timeout 才切到第二个；resolv.conf 的 options timeout 还是默认五秒，重试两次就是十秒起步；查询类型是 AAAA，内网 DNS 对 IPv6 查询直接不回包。
上来先确认哪台服务器不回包
dig +stats api.example.com @10.0.0.2 | grep -E 'Query time|SERVER'随后用固定超时和重试再测一次
dig +time=1 +tries=1 api.example.com然后把 A 和 AAAA 分开看
dig +short A api.example.com && dig +short AAAA api.example.com缩短超时并只保留可用的 DNS
printf '%s
' 'options timeout:1 attempts:2 single-request-reopen' 'nameserver 10.0.0.2' > /etc/resolv.conf这类问题以前遇到过，但这次的触发条件和上次不一样。
这类改动我都写进变更记录，过两周再出问题时能对上号。
别只看报错消失，验证要多做一步。dig 的 Query time 降到 50ms 以内，应用解析失败率归零，nslookup 与 dig 的答案一致。
resolv.conf 会被 NetworkManager 或 cloud-init 覆盖，要改就改对应的模板；内网 DNS 丢 AAAA 查询是老问题，禁掉 IPv6 查询能立刻见效。这类问题最好一次改到位，反复小改反而容易把原因搅混。