I just updated a lot of Raspberry Pis and other machines to Debian Stretch and while doing that (and repairing some broken stuff due to the upgrade) I noticed that my ping startup times, so the time till I see the actual first response, is really bad on some machines. I've been running the same configuration on a lot of different machines up to now, so I'm not actually sure if that is new and I just did not notice, or if this is actually related to the upgrade.To put it into shell output, here is what I see:time ping -c1 serverfault.comPING 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 0msrtt min/avg/max/mdev = 29.085/29.085/29.085/0.000 msreal    0m5.098suser    0m0.010ssys     0m0.000sA second call will be cached, thus shows the expected behaviour:time ping -c1 serverfault.comPING 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 0msrtt min/avg/max/mdev = 16.819/16.819/16.819/0.000 msreal    0m0.063suser    0m0.000ssys     0m0.020sThe funny thing about this is that it is actually not the upstream servers: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)So, as you can see I get a response pretty quickly.Even when I look only at the local loopback the answer when issuing a ping command is more or less instantly: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)But then ping blocks and apparently retries (I see that from the tcpdumps) and then only accepts the answer?When I dig I only see sub 100ms answers. That somehow feels as if ping (or something in the libraries) does not accept this first answer that comes from dnsmasq and needs the cached answer somehow. I can measure this with other tools too (curl, etc). That somehow defeats the purpose of having dnsmasq in the first place. I played around with basically all my dns related options in the config, but to no ends (dnssec, cache sizes, etc). I always have this five seconds delay on the first use.  Any other ideas where to look? Am I interpreting something wrong? I'm pretty much out of ideas now. UpdateSome more things I tried and observations: When I disable the cache in dnsmasq completely, I still have the delays, just everytime I start the ping now.ping -4 does not show the delays, though ipv6 is disabled via sysctl.Addingoptions single-requestto /etc/resolv.conf makes it go away. So apparently an issue with the parallel requests. I will go and ask the mailing list.
Dnsmasq makes ping start slowly
networking;ping;dnsmasq