我刚刚将大量 Raspberry Pi 和其他机器更新为 Debian Stretch，在执行此操作（并修复因升级而损坏的一些内容）的同时，我注意到我的 ping 启动时间，因此直到我看到实际的第一个响应的时间确实是在某些机器上不好。到目前为止，我一直在很多不同的机器上运行相同的配置，所以我实际上不确定这是否是新的，我只是没有注意到，或者这是否实际上与升级有关。
要将其放入 shell 输出中，我看到的是：
time ping -c1 serverfault.com
PING serverfault.com (151.101.193.69) 56(84) bytes of data.
64 bytes from 151.101.193.69 (151.101.193.69): icmp_seq=1 ttl=56 time=29.0 ms
--- serverfault.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 29.085/29.085/29.085/0.000 ms
real 0m5.098s
user 0m0.010s
sys 0m0.000s
第二个调用将被缓存，从而显示预期的行为：
time ping -c1 serverfault.com
PING serverfault.com (151.101.1.69) 56(84) bytes of data.
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=56 time=16.8 ms
--- serverfault.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.819/16.819/16.819/0.000 ms
real 0m0.063s
user 0m0.000s
sys 0m0.020s
有趣的是，它实际上不是上游服务器：
19:49:38.040549 IP (tos 0x0, ttl 64, id 37883, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 10.179.1.1.53: [bad udp cksum 0x17ac -> 0xe329!] 54130+ A? serverfault.com. (33)
19:49:38.040624 IP (tos 0x0, ttl 64, id 6297, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 208.67.220.220.53: [bad udp cksum 0xb918 -> 0x41bd!] 54130+ A? serverfault.com. (33)
19:49:38.040657 IP (tos 0x0, ttl 64, id 25130, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 208.67.222.222.53: [bad udp cksum 0xbb1a -> 0x3fbb!] 54130+ A? serverfault.com. (33)
19:49:38.040688 IP (tos 0x0, ttl 64, id 62720, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 83.169.184.33.53: [bad udp cksum 0x17c3 -> 0xe312!] 54130+ A? serverfault.com. (33)
19:49:38.040717 IP (tos 0x0, ttl 64, id 40746, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 83.169.184.97.53: [bad udp cksum 0x1803 -> 0xe2d2!] 54130+ A? serverfault.com. (33)
19:49:38.040744 IP (tos 0x0, ttl 64, id 41541, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 8.8.4.4.53: [bad udp cksum 0x1804 -> 0xe2d1!] 54130+ A? serverfault.com. (33)
19:49:38.040773 IP (tos 0x0, ttl 64, id 58321, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.37868 > 8.8.8.8.53: [bad udp cksum 0x1c08 -> 0xdecd!] 54130+ A? serverfault.com. (33)
19:49:38.041061 IP (tos 0x0, ttl 64, id 37884, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.35828 > 10.179.1.1.53: [bad udp cksum 0x17ac -> 0xe101!] 49810+ AAAA? serverfault.com. (33)
19:49:38.041120 IP (tos 0x0, ttl 64, id 25131, offset 0, flags [DF], proto UDP (17), length 61)
10.179.1.11.35828 > 208.67.222.222.53: [bad udp cksum 0xbb1a -> 0x3d93!] 49810+ AAAA? serverfault.com. (33)
19:49:38.049748 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 125)
10.179.1.1.53 > 10.179.1.11.37868: [udp sum ok] 54130 q: A? serverfault.com. 4/0/0 serverfault.com. [4m46s] A 151.101.129.69, serverfault.com. [4m46s] A 151.101.65.69, serverfault.com. [4m46s] A 151.101.1.69, serverfault.com. [4m46s] A 151.101.193.69 (97)
19:49:38.054841 IP (tos 0x0, ttl 57, id 43395, offset 0, flags [DF], proto UDP (17), length 125)
208.67.222.222.53 > 10.179.1.11.37868: [udp sum ok] 54130 q: A? serverfault.com. 4/0/0 serverfault.com. [3m7s] A 151.101.129.69, serverfault.com. [3m7s] A 151.101.193.69, serverfault.com. [3m7s] A 151.101.1.69, serverfault.com. [3m7s] A 151.101.65.69 (97)
19:49:38.074955 IP (tos 0x0, ttl 57, id 53865, offset 0, flags [DF], proto UDP (17), length 125)
208.67.220.220.53 > 10.179.1.11.37868: [udp sum ok] 54130 q: A? serverfault.com. 4/0/0 serverfault.com. [5m] A 151.101.1.69, serverfault.com. [5m] A 151.101.65.69, serverfault.com. [5m] A 151.101.129.69, serverfault.com. [5m] A 151.101.193.69 (97)
所以，正如你所看到的，我很快就得到了回复。即使当我只查看本地环回时，发出 ping 命令时的答案或多或少是立即的：
19:50:48.577615 IP (tos 0x0, ttl 64, id 29962, offset 0, flags [DF], proto UDP (17), length 61)
127.0.0.1.45851 > 127.0.0.1.53: [bad udp cksum 0xfe3c -> 0x12d5!] 40455+ A? serverfault.com. (33)
19:50:48.578344 IP (tos 0x0, ttl 64, id 29963, offset 0, flags [DF], proto UDP (17), length 61)
127.0.0.1.45851 > 127.0.0.1.53: [bad udp cksum 0xfe3c -> 0xab1d!] 60094+ AAAA? serverfault.com. (33)
19:50:48.591133 IP (tos 0x0, ttl 64, id 29964, offset 0, flags [DF], proto UDP (17), length 125)
127.0.0.1.53 > 127.0.0.1.45851: [bad udp cksum 0xfe7c -> 0x3aea!] 40455 q: A? serverfault.com. 4/0/0 serverfault.com. [3m36s] A 151.101.129.69, serverfault.com. [3m36s] A 151.101.65.69, serverfault.com. [3m36s] A 151.101.1.69, serverfault.com. [3m36s] A 151.101.193.69 (97)
但随后 ping 会阻塞并显然重试（我从 tcpdump 中看到这一点），然后只接受答案？
当我挖掘时，我只看到 100 毫秒以下的答案。不知怎的，感觉好像 ping （或库中的某些东西）不接受来自 dnsmasq 的第一个答案，并且需要以某种方式“缓存”答案。
我也可以用其他工具（curl 等）来测量它。这在某种程度上违背了 dnsmasq 的初衷。我基本上尝试了配置中所有与 dns 相关的选项，但没有结果（dnssec、缓存大小等）。我第一次使用时总是有五秒钟的延迟。
还有其他想法去哪里看吗？我解释错了吗？我现在几乎没有想法了。
更新 我尝试和观察的其他一些事情：当我完全禁用 dnsmasq 中的缓存时，我仍然有延迟，只是每次我现在开始 ping 时。
尽管通过 sysctl 禁用了 ipv6，但 ping -4 并未显示延迟。
添加
options single-request
/etc/resolv.conf 使其消失。显然并行请求存在问题。我会去询问邮件列表。