unbound: update DNSSEC trust anchor

[shdwchn10]

📦 Package Details

Maintainer: Missing

Description:
Prepare for root zone KSK rollover. After October 11th, new installations of unbound on OpenWrt devices will be unable to validate DNSSEC records due to an outdated trust anchor. Existing installations have been updated to a new trust anchor in accordance with RFC 5011.

The root.key file was last updated 9 years ago.
KSK-2010 has since been deprecated and after 2026-10-11, KSK-2024 will be used to sign the root zone instead of KSK-2017.

---

🧪 Run Testing Details

• OpenWrt Version: 25.12.5
• OpenWrt Target/Subtarget: mediatek/mt7622
• OpenWrt Device: Xiaomi AX6S

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[BKPepe]

The description and commit message make a rather strong claim that new Unbound installations will be unable to validate DNSSEC after October 11th due to the outdated trust anchor.

Could you provide a source for this? In particular, I'd like to understand why KSK-2010 being present in root.key would cause DNSSEC validation to stop working after the rollover, rather than Unbound simply updating the trust anchor through RFC 5011 as it does on existing installations.

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

Verification notes: the new DS record is byte-identical to the one already carried in-tree by net/knot-resolver/files/root.keys, which lists the same 20326 + 38696 pair — so the KSK-2024 key tag and SHA-256 digest match another anchor file in this feed, and unbound was the last package here still shipping KSK-2010. PKG_RELEASE is correctly incremented (shipped data changed, PKG_VERSION unchanged), and KSK-2017 is retained, so the anchor set stays valid both before and after the rollover.

---

Generated by Claude Code

[shdwchn10]

The description and commit message make a rather strong claim that new Unbound installations will be unable to validate DNSSEC after October 11th due to the outdated trust anchor.

Could you provide a source for this? In particular, I'd like to understand why KSK-2010 being present in root.key would cause DNSSEC validation to stop working after the rollover, rather than Unbound simply updating the trust anchor through RFC 5011 as it does on existing installations.

KSK-2010 hasn't been used for many years and its presence in the trust anchor won't affect the functionality of DNSSEC validation. This key should not be used for verification because trust in it has been revoked.

New unbound installations won't be able to obtain a new trust anchor through RFC 5011 because this mechanism exists for planned trust anchor rollover, not for cold starting it without a valid trust anchor in place. KSK-2024 was published on the root servers in February 2025 and is expected to be present in all trust anchors by today. The RFC 5011 mechanism relies on the fact that the new KSK is published in advance in the zone through the DNSKEY record and is signed with the currently trusted KSK key. This way the chain of trust isn't broken. After the KSK rollover on 2026-10-11, the DNSKEY RRset will be signed exclusively by the new KSK-2024. After this event, systems that don't have the KSK-2024 in the trust anchor can't rely on RFC 5011, because the DNSKEY will be signed with an untrusted KSK key. Therefore, for a cold start you need a relevant trust anchor, and RFC 5011 is not intended for such a scenario.