Dnsmasq faz o ping iniciar devagar

Question

Acabei de atualizar muitas Raspberry Pis e outras máquinas para o Debian Stretch e enquanto fazia isso (e consertando algumas coisas quebradas devido à atualização) notei que meus tempos de inicialização de ping, então o tempo até eu ver a primeira resposta real , é muito ruim em algumas máquinas. Eu tenho executado a mesma configuração em muitas máquinas diferentes até agora, então eu não tenho certeza se isso é novo e eu simplesmente não percebi, ou se isso está realmente relacionado à atualização.

Para colocá-lo na saída do shell, aqui está o que eu vejo:

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

Uma segunda chamada será armazenada em cache, mostrando o comportamento esperado:

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

O engraçado disso é que na verdade não são os servidores upstream:

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)

Então, como você pode ver, recebo uma resposta rapidamente. Mesmo quando vejo apenas o loopback local, a resposta ao emitir um comando ping é mais ou menos instantânea:

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)

Mas então o ping bloqueia e aparentemente tenta novamente (vejo isso nos tcpdumps) e só aceita a resposta?

Quando cavo, vejo apenas respostas de menos de 100 ms. Que de alguma forma parece que ping (ou algo nas bibliotecas) não aceita essa primeira resposta que vem do dnsmasq e precisa da resposta "em cache" de alguma forma.

Eu posso medir isso com outras ferramentas também (curl, etc). Que de alguma forma derrota o propósito de ter dnsmasq em primeiro lugar. Eu brinquei com basicamente todas as minhas opções relacionadas ao dns na configuração, mas sem fins (dnssec, tamanhos de cache, etc). Eu sempre tenho cinco segundos de atraso no primeiro uso.

Alguma outra ideia para onde procurar? Estou interpretando algo errado? Estou praticamente sem ideias agora.

Atualizar Mais algumas coisas que eu tentei e observações: Quando eu desabilito o cache no dnsmasq completamente, eu ainda tenho atrasos, apenas toda vez que eu inicio o ping agora.

O

ping -4 não mostra os atrasos, embora o ipv6 esteja desativado via sysctl.

Adicionando

options single-request

para /etc/resolv.conf faz isso ir embora. Então, aparentemente, um problema com os pedidos paralelos. Eu irei pedir a lista de discussão.