gpg2 -v --debug-all --refresh-keys
gpg: Optionen werden aus '/home/rico/.gnupg/gpg.conf' gelesen
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
[... stripped - wk ...]
gpg: DBG: chan_5 <- # Home: /home/rico/.gnupg
gpg: DBG: chan_5 <- # Config: [none]
gpg: DBG: chan_5 <- OK Dirmngr 2.2.3 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_5 -> GETINFO version
gpg: DBG: chan_5 <- D 2.2.3
gpg: DBG: chan_5 <- OK
gpg: DBG: chan_5 -> KEYSERVER --clear hkp://keys.gnupg.net
gpg: DBG: chan_5 <- OK
gpg: DBG: chan_5 -> KEYSERVER
gpg: DBG: chan_5 <- S KEYSERVER hkp://keys.gnupg.net
gpg: DBG: chan_5 <- OK
gpg: 4 Schlüssel werden per hkp://keys.gnupg.net aktualisiert
gpg: DBG: chan_5 -> KS_GET -- (4 KEYS HERE, I REMOVED THEM FOR PRIVACY REASONS)
gpg: DBG: chan_5 <- ERR 219 Server zeigt einen unbestimmten Fehler an <Quelle nicht angegeben>
gpg: Refresh vom Schlüsselserver fehlgeschlagen: Server zeigt einen unbestimmten Fehler an
[... stripped ...]
Description
Details
- Version
- gpg (GnuPG) 2.2.3
Event Timeline
Please do not paste such long debug messages - they are not helpful. Please try to explain the error. From what I can see from that long dump the DNS server failed.
What is your OS? Why is gpg 2.2.3 installed as gpg2 (which is not the default).?
To debug the DNS server you should check your resolv.conf and add this to scdaemon.conf
log-file /foo/bar/scd.log verbose debug ipc,dns
and restart dirmngr (gpgconf --kill dirmngr). The try again and send the scd.log.
I am using an Antergos Linux (Arch Linux).
"Why is gpg 2.2.3 installed as gpg2 (which is not the default).?" What should be the default?
I did not find a scdaemon.conf, so I tried the locations in /etc/scdaemon.conf and in ~/.gnupg/scdaemon.conf
The logfile (in /tmp/) was not created.
Btw: I'm not using smartcards, so why are we using sc-daemon?
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.