Problem refreshing keys

[Phil Pennock]

On 2018-06-12 at 10:05 -0400, Jerry wrote:
> Starting C:\Program Files (x86)\GnuPG\bin\gpg.exe --display-charset utf-8 --refresh-keys... 
> gpg: refreshing 387 keys from hkps://hkps.pool.sks-keyservers.net 
> gpg: keyserver refresh failed: Server indicated a failure
> 
> This is happening on a Windows 10 PRO / amd64 machine. This has been occurring
> for several days now. Is there something wrong with the server?

Seems likely, but there's not enough information there to track it down.

hkps.pool.sks-keyservers.net is a collection of servers, run by
different people, with management software tracking their status and
updating DNS as needed.

I've no idea how to use Kleopatra to ask for more debugging details to
get the IP, sorry.

You can see some of what's going on with:

  gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye

(if Windows doesn't like that quoting, then press enter after --dirmngr
and then enter each of the next strings as a command at the prompt)

Eg, I see:

% gpg-connect-agent --dirmngr 'KEYSERVER --hosttable' /bye
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S #   0       hkps.pool.sks-keyservers.net
S #   .       hkps.pool.sks-keyservers.net
S #   .   --> 4 9* 3 2 1 8 7 6 5
S #   1   4   216.66.15.2
S #   2   4   193.224.163.43 (hufu.ki.iif.hu)
S #   3   4   193.164.133.100 (mail.b4ckbone.de)
S #   4   4   176.9.147.41 (mail.ntzwrk.org)
S #   5   4   92.43.111.21 (oteiza.siccegge.de)
S #   6   4   68.187.0.77 (stlhs.archreactor.org)
S #   7   4   51.15.53.138 (ams.sks.heypete.com)
S #   8   4   37.191.226.104 (host-37-191-226-104.lynet.no)
S #   9   4   18.191.65.131 (ec2-18-191-65-131.us-east-2.compute.amazonaws.com)
OK

So the "." lines are because the previous item is a pool, so they
provide more information, and AFAICT the "-->" line is "the order we'll
try them in, with the currently active server marked with "*"; this
shows me that the second item is active.  This makes sense, since the
first retrieval took a long time, but the second was very quick: the
first keyserver failed to give something sane back, so dirmngr fell over
to the next item, which responded, and dirmngr has remembered that one
as "good" so it will use it again in future.

Given the failure you see, the "blind stabbing in the dark" approach
would be to use:

  KEYSERVER --dead IP.ADD.RE.SS

to mark the one with a "*" as "bad" and see what happens.  If that fixes
it, then you know that the IP address which was "responding" and so
selected was actually failing.  You can drop a note to
sks-devel at nongnu.org with details if you manage to extract that much
information from the tooling.

-Phil, whose keyserver is in the pool and, coincidentally, is #9 above,
       the one which worked and was selected.