Figuring out what dirmngr is doing in these cases, can be aided with cranking up verbosity and logging the output, e.g.:
keyserver hkp://ipv6.pool.sks-keyservers.net
log-file /tmp/tmp.pVKaTIdXs8/.gnupg/dirmngr.log
debug-level guru
Options in $GNUPGHOME/dirmngr.conf. Followed by gpgconf --kill dirmngr.
Whilst plenty of stuff is logged.... it doesn't actually tell me if he hit things over ipv6 or ipv4. It appears to be resolving a pool and picking a random thing to connect to.
dirmngr supposed to figure out that something is dead, is retry elsewhere. Does using hkp://ipv6.pool.sks-keyservers.net improve things for you? That pool should have all servers accessible over ipv6, unlike the main pool which may have ipv4-only servers.
Could you please crank up the logging, and check if it has excessive amount of resolving dns pools and messages marking them dead?
Figuring out what dirmngr is doing in these cases, can be aided with cranking up verbosity and logging the output, e.g.:
keyserver hkp://ipv6. pool.sks- keyservers. net pVKaTIdXs8/ .gnupg/ dirmngr. log
log-file /tmp/tmp.
debug-level guru
Options in $GNUPGHOME/ dirmngr. conf. Followed by gpgconf --kill dirmngr.
Whilst plenty of stuff is logged.... it doesn't actually tell me if he hit things over ipv6 or ipv4. It appears to be resolving a pool and picking a random thing to connect to.
Note the https:/ /bugs.gnupg. org/gnupg/ issue1989
dirmngr supposed to figure out that something is dead, is retry elsewhere. Does using hkp://ipv6. pool.sks- keyservers. net improve things for you? That pool should have all servers accessible over ipv6, unlike the main pool which may have ipv4-only servers.
Could you please crank up the logging, and check if it has excessive amount of resolving dns pools and messages marking them dead?