On 2016-08-12 09:26:10 +0200, Aurelien Jarno wrote:
> The libc does a first connection to the configured name server
> (192.168.0.1) using UDP. Note the size of the packet, very close to
> the 512 bytes limit without EDNS0 support. This very likely mean the
> answer is marked as truncated (look at the number of entries in the
> host answer).
According to tcpdump output below, there is no truncation: the number
of A's and AAAA's (10 for each) match what "host keys.gnupg.net"
gives. BTW, even if there were a truncation, there shouldn't be a
failure: using of the returned IP addresses would be sufficient to
connect.
11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A?
keys.gnupg.net. (32)
11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ AAAA?
keys.gnupg.net. (32)
11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR?
1.0.168.192.in-addr.arpa. (42)
11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 NXDomain* 0/1/0
(94)
11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR?
6.0.168.192.in-addr.arpa. (42)
11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 CNAME
pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 78.46.223.54, A
131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 209.135.211.141, A
5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
11:55:59.184491 IP 192.168.0.1.domain > 192.168.0.6.43592: 23396 NXDomain*
0/1/0 (94)
11:56:04.102206 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A?
keys.gnupg.net. (32)
11:56:04.141278 ARP, Request who-has 192.168.0.6 tell 192.168.0.1, length 28
11:56:04.141296 ARP, Reply 192.168.0.6 is-at cc:3d:82:a9:e3:ea (oui Unknown),
length 28
11:56:04.144746 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 CNAME
pool.sks-keyservers.net., A 193.17.17.6, A 68.187.0.77, A 5.135.158.148, A
151.252.40.184, A 198.128.3.63, A 78.46.223.54, A 131.175.15.4, A
209.135.211.141, A 5.9.50.141, A 93.94.119.246 (502)
11:56:04.144795 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ AAAA?
keys.gnupg.net. (32)
11:56:04.186687 IP 192.168.0.1.domain > 192.168.0.6.41008: 31606| 11/8/0 CNAME
pool.sks-keyservers.net., AAAA 2a01:7e00::f03c:91ff:fe69:8da9, AAAA
2a05:8b81:1000:76::d239, AAAA 2001:6f8:1c3c:babe::62:1, AAAA
2001:4c80:40:628:5c70:d1ff:fe44:1424, AAAA 2001:67c:26b4::2c6b, AAAA
2a01:4f8:161:4283:1000::203, AAAA 2a02:c200:1:10:2:6:4251:1, AAAA
2001:720:418:caf1::8, AAAA 2001:470:d:367::555, AAAA 2a01:7a0:1::6 (500)
11:56:04.186787 IP 192.168.0.6.36060 > 192.168.0.1.domain: Flags [S], seq
206201484, win 29200, options [mss 1460,sackOK,TS val 69369420 ecr 0,nop,wscale
7], length 0
11:56:04.188240 IP 192.168.0.1.domain > 192.168.0.6.36060: Flags [R.], seq 0,
ack 206201485, win 0, length 0
11:56:04.188296 IP 192.168.0.6.36366 > 192.168.0.1.domain: 19382+ A?
keys.gnupg.net. (32)
11:56:04.229939 IP 192.168.0.1.domain > 192.168.0.6.36366: 19382 11/9/5 CNAME
pool.sks-keyservers.net., A 93.94.119.246, A 209.135.211.141, A 78.46.223.54, A
5.135.158.148, A 151.252.40.184, A 5.9.50.141, A 193.17.17.6, A 131.175.15.4, A
198.128.3.63, A 68.187.0.77 (502)
11:56:04.229992 IP 192.168.0.6.36366 > 192.168.0.1.domain: 13056+ AAAA?
keys.gnupg.net. (32)
11:56:04.271424 IP 192.168.0.1.domain > 192.168.0.6.36366: 13056| 11/8/0 CNAME
pool.sks-keyservers.net., AAAA 2a01:7e00::f03c:91ff:fe69:8da9, AAAA
2a02:c200:1:10:2:6:4251:1, AAAA 2001:67c:26b4::2c6b, AAAA
2a05:8b81:1000:76::d239, AAAA 2001:470:d:367::555, AAAA
2001:4c80:40:628:5c70:d1ff:fe44:1424, AAAA 2001:6f8:1c3c:babe::62:1, AAAA
2a01:7a0:1::6, AAAA 2a01:4f8:161:4283:1000::203, AAAA 2001:720:418:caf1::8 (500)
11:56:04.271501 IP 192.168.0.6.36062 > 192.168.0.1.domain: Flags [S], seq
3864689937, win 29200, options [mss 1460,sackOK,TS val 69369441 ecr
0,nop,wscale 7], length 0
11:56:04.272936 IP 192.168.0.1.domain > 192.168.0.6.36062: Flags [R.], seq 0,
ack 3864689938, win 0, length 0
> It therefore looks to me like a bug with your network setup, not a
> libc one.
Well, though I didn't want that, this is quite a standard network
setup: my machine just uses DHCP with some standard ADSL modem
router. And given that many users have similar issues and there
isn't any problem with Android, I suppose that there's some bug
on the libc side (or libc can be improved).
FYI, I also often get 5-second timeouts in name resolution whatever
the host (you can see it above): I get the answer for A or AAAA, but
sometimes, the other answer is lost. I have a DHCP hook that tests
whether I'm using this router:
[...]
ping -n -c 1 -I "$interface" "$new_routers" > /dev/null
if grep -i -q $mac /proc/net/arp; then
logger "Google Public DNS with TCP to avoid recurrent timeout"
[...]
and in this case, I use the Google Public DNS with TCP. But for
some reason, it seems that the /proc/net/arp doesn't contain the
MAC address yet (with the ping, this was working in the past, but
this is no longer the case), so that I just get the default DNS
server (/etc/resolv.conf contains "nameserver 192.168.0.1").
So, fixing this DHCP hook to use Google Public DNS with TCP should
solve the issue with keys.gnupg.net, but this is just a workaround
(needed for for other reason). Name resolution should also work
with the DNS server of the router.
On 2016-08-12 10:37:30 +0200, Aurelien Jarno wrote:
> It would be interesting to see what is actually returned by your
> name server (for example with tcpdump), as it seems despite a big number
> of records given the A and AAAA records are done in two different
> queries, they should fit in less than 512 bytes. This is actually what
> the trace from your working server shows. I wouldn't be surprised if
> this name server returns additional records that have not been
> requested.
See tcpdump output above.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
