Bugs related to gnupg's dirmngr component.
Details
Yesterday
New Situation
Once I started testing in logging mode the problem had gone away already. There were some hints to HTTPS certificate issues, but nothing really to blame. Neither with nor without logging the problem could be reproduced after two days of questioning me.
The caching works on the base of the requested domain, that is example.org and not openpgpkey.example.org - thus it should not make a difference when you change your setup. There is an initial test for a cached domain status before the resolving process starts. If you want to look yourself: gnupg/dirmngr/server.c:cmd_wkd_get() and domainfo.c.
Reproducibility
The problem cannot be confirmed generic on domain level. I can reproduce the effect with keys shipped from my domain, i.e. email addresses @shimps.de, but the issue vanishes when I try to reproduce it with email addresses @gnupg.org as e.g. Werner's address.
Thu, Feb 20
Jan 17 2025
Jan 2 2025
Jan 1 2025
Users landing here looking for help.
This looks like a bug with gnutls which is the only tool that fails :
Dec 2 2024
This ticket is obsolete
Nov 29 2024
Fixed in 2.4.6.
Oct 31 2024
Sep 25 2024
Sep 11 2024
Sep 9 2024
Thank you for the bug report and your patch.
Sep 8 2024
Aug 21 2024
Jun 1 2024
An update FYI
Feb 1 2024
Fixed by changing server as noted above.
Thanks for all the help @gniibe.
It should not be removed as I believe it is required to be compliant:
I'm afraid that your particular configuration would cause the problem of the negotiation.
Jan 4 2024
Note that we now have also an option instead of the workaround from 2015
Dec 11 2023
For various reasons dirmngr requires and implements a full resolver and implements that. This way all DNS queries are passed through Tor. Thus this is a feature and not a bug. The error message could be better but we can only return what SOCKS tells us.
Nov 28 2023
Sep 26 2023
Lot's of things changed in the meantime.
HKP keyservers are anyway out of fashion and thus we won't put anymore effort into his part of the code.
Lot's of changes since 2.4.
Jul 4 2023
Jun 22 2023
See for T6545 for a new request to support IDP.
Jun 15 2023
I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add
May 3 2023
I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.