On 2016-08-12 09:26, Aurelien Jarno wrote: > On 2016-08-11 23:33, Vincent Lefevre wrote: > > Package: libc6 > > Version: 2.23-4 > > Severity: normal > > > > I always get the folloing error on this machine: > > > > zira:~> gpg --keyserver-options verbose,debug --keyserver > > hkp://keys.gnupg.net --recv-key 00000000 > > gpg: requesting key 00000000 from hkp server keys.gnupg.net > > gpgkeys: curl version = GnuPG curl-shim > > * HTTP proxy is "null" > > * HTTP URL is > > "http://keys.gnupg.net:11371/pks/lookup?op=get&options=mr&search=0x00000000" > > * SRV tag is "pgpkey-http": host and port may be overridden > > * HTTP auth is "null" > > * HTTP method is GET > > ?: keys.gnupg.net: Host not found > > gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused > > gpg: no valid OpenPGP data found. > > gpg: Total number processed: 0 > > gpg: keyserver communications error: keyserver unreachable > > gpg: keyserver communications error: public key not found > > gpg: keyserver receive failed: public key not found > > zsh: exit 2 gpg --keyserver-options verbose,debug --keyserver > > hkp://keys.gnupg.net > > > > even though the host exists: > > > > zira:~> host keys.gnupg.net > > keys.gnupg.net is an alias for pool.sks-keyservers.net. > > pool.sks-keyservers.net has address 5.9.50.141 > > pool.sks-keyservers.net has address 91.143.92.136 > > pool.sks-keyservers.net has address 108.18.103.116 > > pool.sks-keyservers.net has address 131.155.141.70 > > pool.sks-keyservers.net has address 85.10.205.199 > > pool.sks-keyservers.net has address 163.172.29.20 > > pool.sks-keyservers.net has address 104.236.209.43 > > pool.sks-keyservers.net has address 84.200.66.125 > > pool.sks-keyservers.net has address 5.9.143.170 > > pool.sks-keyservers.net has address 185.95.216.79 > > pool.sks-keyservers.net has IPv6 address 2607:5300:60:490f:1::19 > > pool.sks-keyservers.net has IPv6 address 2604:a880:800:10::227:e001 > > pool.sks-keyservers.net has IPv6 address 2001:41d0:2:55c2:5054:ff:fe12:3 > > pool.sks-keyservers.net has IPv6 address 2a01:4f8:a0:4024::2:0 > > pool.sks-keyservers.net has IPv6 address 2a02:180:a:65:2456:6542:1101:1010 > > pool.sks-keyservers.net has IPv6 address 2a01:4f8:d16:24c1::2 > > pool.sks-keyservers.net has IPv6 address 2a01:7c8:aabc:45a:5054:ff:fe9b:59a3 > > pool.sks-keyservers.net has IPv6 address 2001:470:d:367::555 > > pool.sks-keyservers.net has IPv6 address 2a01:4f8:161:4283:1000::203 > > pool.sks-keyservers.net has IPv6 address > > 2001:4c80:40:628:5c70:d1ff:fe44:1424 > > > > This seems to be a known issue: > > > > https://lists.gnupg.org/pipermail/gnupg-users/2015-October/054532.html > > > > (searching for "keys.gnupg.net: Host not found" gives much more > > examples). > > > > I wondered whether this was a bug from gnupg, until I tried: > > > > zira:~> ping keys.gnupg.net > > ping: keys.gnupg.net: Temporary failure in name resolution > > zsh: exit 2 ping keys.gnupg.net > > > > which I always get. Ditto with telnet. > > > > An excerpt of the strace for gnupg: > > > > 30419 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0 > > 30419 socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 4 > > 30419 connect(4, {sa_family=AF_INET, sin_port=htons(53), > > sin_addr=inet_addr("192.168.0.1")}, 16) = 0 > > 30419 poll([{fd=4, events=POLLOUT}], 1, 0) = 1 ([{fd=4, revents=POLLOUT}]) > > 30419 sendmmsg(4, {{{msg_name(0)=NULL, > > msg_iov(1)=[{"\343\376\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\1\0\1", > > 32}], msg_controllen=0, msg_flags=0}, 32}, {{msg_name(0)=NULL, > > msg_iov(1)=[{"'J\1\0\0\1\0\0\0\0\0\0\4keys\5gnupg\3net\0\0\34\0\1", 32}], > > msg_controllen=0, msg_flags=0}, 32}}, 2, MSG_NOSIGNAL) = 2 > > 30419 poll([{fd=4, events=POLLIN}], 1, 5000) = 1 ([{fd=4, revents=POLLIN}]) > > 30419 ioctl(4, FIONREAD, [500]) = 0 > > 30419 recvfrom(4, > > "'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, > > {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.0.1")}, > > [16]) = 500 > > 30419 close(4) = 0 > > 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).
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. I guess you can also workaround the issue by activating edns0 (adding an "options edns0" line in /etc/resolv.conf) which allows UDP queries bigger than 512 bytes. This however requires that your name server supports that. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net