dirmngr fails with IPv6 nameserver in resolv.conf
Closed, ResolvedPublic

nfnty set Version to 2.1.19.
nfnty added a subscriber: nfnty.Mar 9 2017, 3:27 PM

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
werner added a subscriber: werner.Mar 10 2017, 10:49 AM

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.

nfnty added a comment.Mar 10 2017, 2:01 PM

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

nfnty added a comment.Mar 10 2017, 2:02 PM

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

nfnty added a comment.Mar 10 2017, 2:02 PM

nfnty added a comment.Mar 10 2017, 2:03 PM

nfnty added a comment.Mar 10 2017, 2:03 PM

And failing with IPv6 nameserver.

nfnty added a comment.Mar 13 2017, 3:52 PM

#2991 is a duplicate of this issue.

arian added a subscriber: arian.May 27 2017, 11:39 PM

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.
justus edited projects, added gnupg (gpg22); removed gnupg.May 29 2017, 9:38 AM
justus moved this task from Backlog to Blocker on the gnupg (gpg22) board.
justus claimed this task.Jun 12 2017, 4:59 PM
justus raised the priority of this task from Normal to High.

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

justus closed this task as Resolved.Jun 13 2017, 12:01 PM