测递归DNS响应速度需排除本地干扰、模拟真实路径、多次采样并关注稳定性：①用dig @IP +stats测单次真实耗时；②用time包裹dig看real时间评估端到端延迟；③批量循环测试计算平均值、抖动与失败率；④横向对比多个DNS服务器响应差异。
直接测递归DNS服务器的响应速度，关键不是“跑一次dig就看Query time”，而是要排除本地干扰、模拟真实查询路径、做多次采样并关注稳定性。下面这几个方法最实用、最贴近生产排查场景。
用 dig 指定服务器 + 统计模式测单次真实耗时
这是最常用也最可靠的方式。重点在于绕过系统默认配置和缓存：
- 加 @IP 强制发往目标递归服务器（比如
dig google.com @8.8.8.8），不走/etc/resolv.conf或 systemd-resolved - 加 +stats 显示详细时间，其中 Query time 就是该次UDP请求从发出到收到响应的毫秒数
- 加 +short 可精简输出，方便脚本解析；加 +noall +answer 更干净
- 避免 IPv6 干扰：加 -4 强制只查 A 记录，防止因 AAAA 查询超时拖慢结果
用 time + dig 做毫秒级端到端测量
dig 的 Query time 只反映 DNS 协议层耗时，但实际网络链路（如路由、防火墙、中间设备）的影响也要考虑。这时用 time 包一层更真实：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
time dig +short example.com @1.1.1.1 -4- 注意看
real时间（真实经过时间），它包含进程启动、网络往返、系统调度等全部开销 - 对比
real和 dig 输出里的Query time：如果差值大，说明本地处理或网络延迟高，不是DNS服务器本身慢
批量测试 + 统计分析判断稳定性
单次结果意义有限。递归DNS性能要看平均响应、抖动、失败率：
- 写个简单循环测 10–50 次：
for i in {1..20}; do dig +short google.com @9.9.9.9 -4 +stats 2>&1 | grep "Query time"; done - 把所有 Query time 提取出来，用
awk算平均、最大、最小、标准差：... | awk '{sum+=$4; n++} END {print "avg="sum/n, "max="max, "stddev="sqrt((sum2 - sum^2/n)/n)}' - 观察是否出现超时（Query time 显示 “;; connection timed out”）或返回 SERVFAIL —— 这比慢更严重，说明服务异常
对比多个递归服务器横向评估
别只盯一个。拿几个主流公共DNS一起测，能看出相对优劣：
- Google：
dig google.com @8.8.8.8 -4 +stats - Cloudflare：
dig google.com @1.1.1.1 -4 +stats - Quad9：
dig google.com @9.9.9.9 -4 +stats - 国内可加 AliDNS（223.5.5.5）或 TencentDNS（119.29.29.29）
- 注意：不同服务器对同一域名的响应时间可能差异很大，因为地理位置、缓存命中率、上游链路都不同
