应用侧验证是什么
工具查得通不代表应用能解析。最后一步必须回到应用所在的运行环境里验证：getent 走的是 NSS 全链路（/etc/nsswitch.conf、resolv.conf、缓存守护进程），strace 则能看出进程实际连了哪台 DNS、连了多久、失败后是否切换到第二台。容器环境下这一步尤其重要，因为容器有独立的 resolv.conf 与网络命名空间。
基本信息
| 适用平台 | Linux（glibc NSS、strace）；容器内需 exec 进入 |
|---|---|
| 核心命令 | getent hosts/ahosts、strace -e trace=connect |
| 关注点 | 解析耗时、实际使用的 DNS 地址、是否发生重试与切换 |
| 关键差异 | dig 直连 DNS，getent 走 NSS，两者结论可能不同 |
典型使用场景
- dig 正常但应用报解析失败：多为 NSS 顺序或缓存守护进程的 hosts 文件优先级问题
- 容器内偶发解析超时：抓出应用实际请求的 DNS 地址与超时次数
- 多台 DNS 配置下的切换行为：确认第一台超时后是否真的切到第二台
- 慢启动排查：把解析耗时与应用启动耗时对账，定位是否卡在解析阶段
应用视角取证
应用视角取证
# 走 NSS 全链路解析，与 dig 的结论可能不同
getent hosts app.example.com
# 分别统计各地址类型的解析耗时
time getent ahosts app.example.com
# 跟踪应用真实的 DNS 与连接行为
strace -f -tt -e trace=connect -s 80 -o /tmp/app-net.log <启动应用或复现命令>
# 从日志里挑出与 53 端口相关的连接尝试
grep ':53' /tmp/app-net.log | head -20结论差异对照
| 现象组合 | 含义 | 下一步 |
|---|---|---|
| dig 通、getent 不通 | NSS 顺序或本地 hosts/cache 干扰 | 检查 nsswitch.conf 与缓存守护进程 |
| getent 通、应用不通 | 应用自带解析（如 Java/Go 自定义解析器）或走了代理 | 确认应用解析实现与代理配置 |
| 应用连的 DNS 与预期不同 | resolv.conf 被覆盖（DHCP 或容器平台） | 核对容器 resolv.conf 与平台注入策略 |
| 解析耗时忽高忽低 | 首台 DNS 超时后切换 | 统计 53 连接的失败与重试次数 |
容器内排查务必用 docker exec 或 kubectl exec 进同一容器执行 getent，别在宿主机上验证：命名空间与 resolv.conf 都不同，宿主机正常不代表容器正常。
strace 会显著降低被跟踪进程的性能并可能干扰时序，只用于短时复现，不要挂在生产主进程上长时间运行。