The stripped down log is
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 28 2018
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.