Linux DNS并发查询超时本质是UDP丢包、递归排队、glibc行为或systemd-resolved队列所致；需用dig+stats测延迟、strace抓系统调用、resolv.conf配single-request-reopen/rotate、resolvectl查缓存、tcpdump验UDP分片。
Linux中DNS解析出现并发查询超时，通常不是系统级“并发数限制”本身导致的，而是由底层机制、配置参数或网络路径共同引发的表象。真正的瓶颈往往藏在UDP响应丢包、递归服务器排队、本地glibc解析器行为或systemd-resolved等代理服务的队列策略里。
查清是不是真发生了“并发超时”
先别急着调参数，得确认问题本质：
- 用dig +stats example.com @8.8.8.8多次执行，看每次查询耗时是否稳定；如果偶尔飙升到1~3秒且Status为NOERROR，说明是单次查询延迟，不是并发被限
- 用dig example.com @127.0.0.53 +short（systemd-resolved默认地址）对比，若明显更慢，说明本地代理层可能积压请求
- 运行strace -e trace=connect,sendto,recvfrom -p $(pgrep your_app)抓应用实际发出的DNS系统调用，观察是否有大量sendto后长时间无recvfrom——这才是并发阻塞的直接证据
检查glibc的resolv.conf控制参数
/etc/resolv.conf不只是写nameserver，它还支持影响并发行为的关键选项：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- options timeout:1 attempts:2：表示每次查询最多等1秒，总共试2次。看似宽松，但若上游DNS响应慢（比如平均400ms），2次重试叠加就容易突破应用侧超时阈值
- options single-request-reopen：老版本glibc默认用同一个socket发多个A/AAAA查询，某些防火墙会误判为异常流量而丢包；加这个选项会让每次查询都新建UDP socket，可绕过路径干扰
- options rotate：多个nameserver间轮询，避免单点卡住拖垮全部查询；没开的话，第一个DNS挂了，后续所有请求都会排队等它超时
排查systemd-resolved的队列与缓存策略
现代发行版（Ubuntu 20.04+/CentOS 8+）默认启用systemd-resolved，它会在127.0.0.53监听，并做缓存和转发。它的并发处理不是无上限的：
- 查看当前状态：systemctl status systemd-resolved，关注“Active: active (running)”及最近是否有“Failed to forward query”日志
- 检查缓存命中率：resolvectl statistics，若“Cache hits”占比极低、“Current transactions”长期>10，说明缓存失效严重或上游响应太慢
- 临时禁用它测试：sudo systemctl stop systemd-resolved && sudo systemctl disable systemd-resolved，再把/etc/resolv.conf硬指向8.8.8.8，看并发表现是否改善
验证UDP分片与防火墙路径是否截断响应
DNS响应超过512字节会触发UDP分片，而很多企业防火墙或QoS设备默认丢弃非首片UDP包——这会导致看似“并发超时”，实则是单个大响应永远收不全：
- 在客户端抓包：tcpdump -i any -n port 53 and udp -w dns.pcap，然后dig一个返回多条A记录的域名（如google.com）
- 用Wireshark打开pcap，过滤udp.length > 512，看是否有“UDP packet size > 512”但只收到第一片、后续missing的情况
- 若确认是分片问题，可在resolv.conf加options edns0启用EDNS(0)，让客户端主动声明支持大包，促使服务器改用TCP回包（TCP无分片风险）
