gpg: error retrieving 'erich at eckner.net' via WKD: Connection closed in DNS
gnupg at eckner.net
Fri Jan 22 18:05:54 CET 2021
-----BEGIN PGP SIGNED MESSAGE-----
first: Maybe I should migrate this discussion to the bug tracker? But I'm
always somewhat hesitant to open new bugs, because I always assume, I'm
just too stupid to properly configure everything :-)
On Fri, 22 Jan 2021, Werner Koch wrote:
> On Fri, 22 Jan 2021 13:24, Erich Eckner said:
>> Box 1: tor (but no DNS endpoint exposed), named listening on 127.0.0.1:53
>> (used by /etc/resolv.conf)
> In Tor mode we use 184.108.40.206 as DNS Server unless you use
> --nameserver ipaddr
> In ``Tor mode'' Dirmngr uses a public resolver via Tor to resolve
> DNS names. If the default public resolver, which is 220.127.116.11,
> shall not be used a different one can be given us‐ ing this option.
> Note that a numerical IP address must be given (IPv6 or IPv4) and
> that no error checking is done for ipaddr.
> this is all implemented using a full DNS resolver library inside dirmngr
> (which you can also truns into a --recursive-resolver). If you don't
> want this, or DNS over Tor and if you are not on Windows you may use
standard-resolver works (in DNS) on box 1, all other options (even
"nameserver 127.0.0.1") give:
4 - 17:25:37 dirmngr[3382567.6]: DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Permission denied
4 - 17:25:37 dirmngr[3382567.6]: DBG: dns: getsrv(_openpgpkey._tcp.eckner.net): Permission denied
However, with "standard-resolver" dns works, but the actual fetch fails:
4 - 17:28:28 dirmngr[3383211.6]: DBG: dns: resolve_dns_name(openpgpkey.eckner.net): Success
4 - 17:28:28 dirmngr[3383211.6]: can't connect to 'openpgpkey.eckner.net': Permission denied
4 - 17:28:28 dirmngr[3383211.6]: error connecting to 'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich': Permission denied
4 - 17:28:28 dirmngr[3383211.6]: command 'WKD_GET' failed: Permission denied
This means, the connection through tor fails, right? This is strange,
because a plain
curl -x socks5h://127.0.0.1:9050 'https://openpgpkey.eckner.net/.well-known/openpgpkey/eckner.net/hu/81t9qcnyscdr3uatodn7eejogt6tpa8q?l=erich'
and also with -4 or -6 works just fine. Looking at tor's log, I see:
Tor: Your application (using socks5 to port 443) is giving Tor
only an IP address. Applications that do DNS resolves themselves may leak
information. Consider using Socks4A (e.g. via privoxy or socat) instead.
For more information, please see
[1 similar message(s) suppressed in last 5 seconds]
This is probably due to "SafeSocks 1" in my torrc. So gnupg resolves the
ip and tries to connect to that directly through tor, but tor refuses to
It would be really nice, if the name resolution could be handed over to
the socks layer, but at least, I now understand, why it fails (and that I
probably have no other choice as to disable SafeSocks in tor or not-use
tor for gpg).
>> Box 2: named listening on 127.0.0.1:53 (used by /etc/resolv.conf), dnsdist
>> listening on $all_public_ips:53 (used by external clients, relaying to
>> named and iodine as needed), iodine listening on 127.0.0.1:5353
>> Does gnupg interpret any of these as tor dns endpoints? How does gnupg
>> determine, how to query dns?
> In non-Tor mode /etc/resolv.conf etc is parsed. --debug dns should show
> errors or fallbacks for unknown statements.
I was more wondering, why gpg decides to go into "tor mode" on box #2,
when there is actually no tor installed or running. I'm totally happy to
force non-tor mode via config file, but I'm also open to help find the
root for gpg's misjudgement of tor-availability.
>> The additional "debug dns" line didn't change anything noticeably for me,
>> I already have "debug ipc,network,dns", so probably it's redundant?
> I see. I would need to check how to enable all DNS debugging. You have
> "verbose" also in your dirmngr.conf?
yes, my current content is:
Note, that I *do* see some dns lines (the ones which I posted earlier).
>> I'd prefer to use tor for retrieving keys (if possible). Is there a
>> possibility to turn off dns resolution via tor, but still do all the rest
>> through tor?
> I don't think so. It is quite some time since I last worked on the Tor
> features. (dirmngr/dns-stuff.c, dirmngr/dns.c are the main files)
Well, from what you wrote before, I understood, that using --nameserver
alongside --use-tor, it would query dns directly and do everything else
through tor. Maybe, I got something wrong. But this doesn't matter,
because I was thinking in the complete wrong direction: If I cannot solve
the dns resolution problem through tor, I also cannot use tor (with my
current tor config) for direct key retrieval.
>> disable-ipv4 / disable-ipv6 does not make any difference (without also
>> adding "no-use-tor", of course)
> Sometimes it makes a difference in particular on my Windows VM.
I agree: Switching between ip versions is always worth a trial
(especially, since my ipv6 @home is actually a 6in4 routed through ukraine
- - and thus also probably russia and the KGB ;-p)
> Build against an older libgpg-error (aka gpgrt) version but that does
> not matter.
>> * GpgRT 1.41-unknown (0000000)
> That is the actual version used.
>> I don't see any libdns there. Box #1 only differs in the cpu flags line:
> No library but the (modified) implementation by William Ahern.
> CPU flags are not relevant here; they are runtime tested.
> * Free Assange and protect free journalism!
> * Germany: Sign the Treaty on the Prohibition of Nuclear Weapons!
P.S.: I liked the old signature better. (Nothing against political
statements, but it was more witty)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users