It looks similar if the key is in a WKD: First search fails without error, only "no certificates found" is shown. Clicking "Search" again results then in the expected key being found and shown.

The advantage of using a fingerprint for referencing a key is that there won't be any collisions in the keyid. Further this unifies the schema with an LDS (Windows) installation where DNs must anyway be unique. But take care the client needs to support this new flag. This will be the case for gnupg >= 2.5.12 (cf. T7756)

Fix pushed by: rG1ed8b0e7b403: dirmngr: Fix libdns with 127.0.0.1.

For Linux kernel, once, it was proposed:
https://patchwork.ozlabs.org/project/netdev/patch/1490748756.24891.27.camel@edumazet-glaptop3.roam.corp.google.com/

Another problem with same cause (possibly) is reported: https://lists.gnupg.org/pipermail/gnupg-devel/2025-April/035845.html

Hey there. I wanted to bring this up again, to see if we can perhaps get this changed after all:

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.