Promiscuous NS RRSets that complement DNS replies in the authority
section can be used to trick resolvers to update their delegation
information for the zone.
We would like to thank Yuxiao Wu, Yunyi Zhang, Baojun Liu and Haixin
Duan from Tsinghua University for discovering and responsibly disclosing
the vulnerability.
Bug Fixes:
- Fix CVE-2025-11411 (possible domain hijacking attack), reported by
Yuxiao Wu, Yunyi Zhang, Baojun Liu and Haixin Duan from Tsinghua
University.
First things first, thank you for the great product.
However, my Fedora package has failed again on PGP key verification. New release is signed with key 948EB42322C5D00B79340F5DCFF3344D9087A490.
My previous key of Wouter were not recognized. Then I realized previous release were not signed by Yorgos. But some previous were. I went to NLNetlabs People page [1] to find who that george might be. And surprise, no George at all.
When I refreshed the key of Yorgos, I found then I am not under attack and I already have such key, but not with this id.
gpgv: Signature made Wed Oct 22 11:16:18 2025 CEST
gpgv: using RSA key 948EB42322C5D00B79340F5DCFF3344D9087A490
gpgv: issuer "george@nlnetlabs.nl"
gpgv: Can't check signature: No public key
Anyway, could be please created one file published over HTTPS, which would contain both people creating source archives recently?
I had to put one key or another key [2] into my spec file, it is somehow unwanted, especially in archive signature verification.
It would be better if unbound page [3] could contain at least description which people may sign the release. Ideally combined single file, which I may refresh on new release if in doubt.
For myself, the announcement 4 days earlier (on the 20th) in the email
with Subject of "Unbound release - introducing extra PGP key" was quite
helpful.
A single keyring for "all keys valid for this product" would be helpful,
albeit too often I'd see folks fetch it just before fetching the
software release assets and verify against the key just retrieved from
the same place and then be confused as to why I'd flag it as an issue.
So it's not as simple as "put it in the same place" and needs very
careful messaging to at least try to discourage people from mistakes.
As to the <https://nlnetlabs.nl/people/> page, Yorgos' key is one of
only three where the key is distributed from a site under their
administrative control instead of the public swamps, so one of only
three which doesn't make me wince. This is a definite improvement.
(If PGP weren't dying such that I'm reluctant to spend effort on
advocacy any more, I'd nudge towards WKD, as used by kernel.org,
debian.org, archlinux.org, etc, so that `gpg --locate-external-keys
foo@nlnetlabs.nl` could work; as it is, I'll leave it as this note that
a world which is simpler for relying parties is possible, if folks are
interested.)
Did you know you can locate gpg keys from DNS itself? It is a bit sad DNS specialized group does not publish it that way. Especially when they already have the domain signed and they could publish the OPENPGPKEY record there.