Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: