Unbound - RFC 5011 Trust Anchor State reset across restarts

Unbound
1

We are running Unbound 1.25.1 on AlmaLinux 10 with the following configuration:

auto-trust-anchor-file: "/var/lib/unbound/root.key"

We have observed an issue with the RFC 5011 trust-anchor update for root KSK-2017 (key ID 38696).

The key remained in ADDPEND state and did not transition to VALID as expected. The root.key file showed the following:

;;state=1 [ ADDPEND ]
;;count=250
;;lastchange=1790564365
;;Mon Sep 28 02:59:25 2026

We expected the key to transition to VALID after the RFC 5011 add hold-down period, but this did not happen.

We believe the failure of the transition is due to our patch lifecycle process in which the servers are updated between 25 and 30 days causing the process to restart, as such restarting the hold-down period

Workaround

We were able to force the key update using:

unbound-anchor -a /var/lib/unbound/root.key -F
unbound-anchor -a /var/lib/unbound/root.key

After this, the key showed VALID:

;;state=2 [ VALID ]
;;count=0
;;lastchange=1791504957
;;Fri Oct  9 00:15:57 2026

However, the running Unbound process did not recognise the updated trust-anchor state until we ran:

unbound-control reload

Without the reload, the following query returned SERVFAIL:

dig @127.0.0.1 root-key-sentinel-is-ta-38696.iana.org +dnssec

We also tried unbound-control fast_reload and unbound-control reload_keep_cache, but neither caused the running validator to recognise the updated anchor.

Questions

  1. should routine Unbound restarts or host reboots as part of our OS patching lifecycle affect the RFC 5011 timer or state progression?

  2. Is this expected behaviour in Unbound 1.25.1, or is there a known issue with RFC 5011 state persistence or processing?

  3. Is there a supported way to make the running validator recognise the updated trust anchor without a full reload and DNS cache flush?