Error output:

dirmngr[9.5]: handler for fd 5 started
dirmngr[9.5]: connection from process 10 (1000:1000)
dirmngr[9.5]: command 'KS_GET' failed: Server indicated a failure <Unspecified
source>
gpg: keyserver receive failed: Server indicated a failure
dirmngr[9.5]: handler for fd 5 terminated

Please add

verbose
debug ipc,dns
log-file /foo/bar/dirmngr.log

to dirmngr.conf, kill dirmngr (gpgconf --kill dirmngr), and retry. Show us the
log then.

What OS are you using? It looks like A Linux distro but the process id 10 is a
little bit unlikely.

Arch Linux. The PID was due to running in a container.

Here's running normally (not in a container) using IPv4 nameserver.

And failing with IPv6 nameserver.

#2991 is a duplicate of this issue.

debian stretch's 2.1.18 also suffers from this (debian bug tracker). As there is only 13 days left for fixing issues in stretch, swift action is needed.

as using sthe standard-resolver solves this, is there an issue using that by default? Which resolver does it actually use, and anyway, why does gnupg not use the standard resolver by default?

in particular, do you see issues with placing

standard-resolver

in /usr/share/gnupg/dirmngr-conf.skel

Dirmngr uses its own resolver for these reasons:

• custom timeout handling.
• forcing use of TCP so to be able to go via Tor.
• common code on all platforms; in particular we can use that resolver also on Windows.

This is fixed now. The fix 15d2a009931f44a60b9df6325f837add208459d6 should be easy to backport.