DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.
Jul 1 2020
Jun 30 2020
The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.
Oct 25 2019
Aug 22 2019
Fixed in master.
This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.
Aug 10 2019
WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:
Aug 6 2019
DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.
I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD?
Jul 11 2019
Is this really necessary to duplicate functionality that already is provided by Web Key Directory?
Jul 10 2019
I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.
Sure it is not validated. Standard clients do not provide the system features to do that. That is one of the problems with DNSSEC adoption - it works only for servers in practice.
Jul 3 2019
I asked you to carry this to a mailing list and not re-open this task.
May 23 2019
Are you not reading what I am saying to you?? Once again, your explanation is INVALID because that would mean that gnupg would be BROKEN, because it would be a NON-COMPLIANT http client according to the RFC I quoted.
I explained why the keyserver access requires access to the DNS. If that is not possible the keyserver code will not work. If you don't allow DNS to work you either have to use Tor (which we use to also tunnel DNS requests) or get your keys from elsewhere. Also note that the keyserver network is current several broken and under DoS and thus it is unlikely that it can be operated in the future.
May 17 2019
Apr 1 2019
HTTP/1.1 spec, RFC 7230, Section 5.4, paragraph 2:
Please be so kind and point me to the specs stating that you should put the IP address into Host:
It's up to GPG to send the Host header that shows the user's intent.
So in short you want:
- Allow to specify a keyserver by IP without any DNS lookups.
- When connecting via IP use the IP address for Host:.
Mar 31 2019
Mar 19 2019
Also might I add, this used to work perfectly fine in gnupg14. It seems that somewhere along the line a regression was introduced that is causing this erroneous non-compliant behavior in the HTTP client.
Why? Your explanation is invalid because it implicates dirmngr's HTTP client as not comforming to the spec laid out by the RFC. I've quite clearly explained--and backed up with the spec itself--that when a proxy variable is configured, a client should not be doing DNS lookup of the destination hostname. Is there something about that you are not understanding?
Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.
Mar 18 2019
Yes you can, and no you do not. Don't believe me? Then read the spec. At no point does the spec say that there is "nothing that can be done" when a hostname cannot be resolved when connecting through a proxy. In fact, it states precisely the opposite, describing the exact procedure a client should take when making a request through a proxy. See section 5.3, paragraph 3:
No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.
Dec 14 2018
So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.
Dec 11 2018
If you specify a pool of keyservers dirmngr selects a keyserver on its won from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.
Oct 25 2018
It seems that this part of the code was not finished. Unfortunately upstream of the dns code is unresponsive and thus we started to maintain the code base by ourselves. There is still an open question whether we should do that to the full extend, in which case we would integrate the code closer into the GnuPG framework with its own logging subsystems.
Aug 21 2018
A workaround for this until the HTTP client is fixed is to just use curl instead:
I am running into the same exact issue. It seems that dirmng is incorrectly attempting to resolve the addresses for the keyservers despite having been given an HTTP proxy to connect through.
Jul 12 2018
Jun 20 2018
Applied to 2.2 branch.
Jun 19 2018
Jun 18 2018
And 2.2 branch.
Fixed in master.
Jun 15 2018
I'll fix for the non-FQDN case.
I think that I identified the issue. This is the libdns (dirmngr/dns.c) problem when hostname is not FQDN.
If you change it to FQDN, you can see that it tries to search adding the domain name.
Fixed in master.
It is indirectly reported at the upstream: https://github.com/wahern/dns/issues/19
Apr 26 2018
Apr 17 2018
An option to ignore SRV records would also be good for debugging. Thus I raised the priority and truned this into a feature request.
@Beiri22: It was my fault to to tell you to use scdaemon.conf. The correct conf file is of course dirmngr.conf. However, with @BenM comments I don't think that it is a bug at all. I am thus closing this; please feel free to re-open if we were wrong
Apr 11 2018
Since the initial redacted data for those four keys is still accessible, I checked all of those keys manually and none of them are on the keyservers. Since the OP was connecting to the specified keyserver successfully prior to that failure, I believe this is the cause of the error and not another DNS vs. Dirmngr conflict.
Apr 9 2018
That slipped my attention due to the missing gpg22 tag I should have added. Sorry.
Is there any ETA for when this might get fixed? We are having the same issue with our keyserver since it's behind a cname.
Feb 28 2018
That will be the IP of proxy.x.com - the log shows that it finds that. But the log also shows that it can't find the address for the other names. "No Name" is EAI_NONAME.
I did some digging with Wireshark:
- there are DNS queries for proxy records A & AAAA (ipv4 & ipv6 - both regardless of --disable-ipv6)
- DNS reply returns correct IP address in A record
- there are no outgoing connections to proxy IP address
Well, if your proxy inhibits GnuPG to retrieve information about the keyservers, GnuPG can't do anything about it.
Just to clarify:
1.I'm behind corporate network
2.Network resolves only local addresses, so this is correct: dirmngr: resolving 'hkps.pool.sks-keyservers.net' failed: No name
3.Network address of the proxy is resolvable (I can see it's address and it responds to ping
4.Internet browser without proxy will not work
5,Internet browser with the proxy below works
6.When using gpg on this computer outside of corporate network everything works
The stripped down log is
Feb 27 2018
@werner Problem persists (same results with disabling ipv4 or ipv6
Feb 22 2018
Feb 21 2018
hm, i think this is the file:
Jan 24 2018
Jan 10 2018
I'm using gnupg 2.2.4 and this problem repros for me, and it impacts downstream things like pacman-key (Arch Linux) quite insidiously, which fails with an misleading error message that would not point a regular user to this line of investigation.
Jan 9 2018
$ gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye OK - Libdns stub resolver
What is the output of
gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye
and what is the content of your /etc/nsswitch.conf and /etc/resolv.conf ? Is there anything special in your /etc/hosts? Are you using any kind of non mainstream DNS resolver on your system or network?
Jan 3 2018
Nov 30 2017
I am using an Antergos Linux (Arch Linux).
Nov 29 2017
For reference here is @mcgrof's dump in a directly readable format:
00:29:33.472844 IP 192.168.4.7.10218 > 192.168.4.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65) 00:29:33.879268 IP 192.168.4.1.domain > 192.168.4.7.10218: 53039 FormErr 0/0/0 (65) 00:29:33.880719 IP 192.168.4.7.10218 > 192.168.4.1.domain: 51133+ Type0 (Class 8448)? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (66) 00:29:33.902115 IP 192.168.4.1.domain > 192.168.4.7.10218: 51133 FormErr 0/0/0 (65)
Nov 21 2017
Unconditionally retrying without SRV lookup is not a good idea. SRV record are there for a reason. What we could do is an option to skip SRV record lookups.