私はちょうどいくつかのRaspberry Piや他のコンピュータをDebian Stretchにアップデートしました。まず、一部のシステムでは、応答時間が実際に悪い。私はこれまでさまざまなシステムで同じ構成を実行してきたので、これが新しいのか、私が気づいていないのか、それとも実際にアップグレードに関連するのかはわかりません。
これをシェル出力に入れると、次のようになります。
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
2番目の呼び出しはキャッシュされ、予想される動作を示します。
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で確認されて）、応答が受け入れられますか？
掘り下げてみると100ms以下の回答だけが見えます。何とかping（またはライブラリ内のもの）がdnsmasqの最初の答えを受け入れず、何とか答えを「キャッシュ」する必要があるように感じます。
他のツール（カールなど）でも測定できます。これはdnsmasqの目的に多少ずれています。デフォルトでは、設定ですべてのDNS関連オプションを試しましたが、結果はありませんでした（dnssec、キャッシュサイズなど）。初めて使用するときは常に5秒の遅延がありました。
どこを見るかについての他のアイデアがありますか？私は間違って説明しましたか？今、アイデアはほとんどなくなりました。
修正する 私が試してみたいくつかの他のこと：dnsmasqでキャッシュを完全に無効にしても、今pingを開始するたびにまだ遅延が発生します。
ipv6 は sysctl で無効になりますが、ping -4 には待ち時間は表示されません。
次へ追加
options single-request
/etc/resolv.conf を消去します。並列要求に問題があるようです。メーリングリストに尋ねます。