Need to run "unbound-anchor" every boot to resolve DNSSEC domains

Installed unbound with the help of pihole documentation guide. but unbound fails to load or trust the anchor at boot. I have to run it then restart the service every boot to enable it

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Sep 27 08:48:15 2020
pi@raspberrypi:~ $ systemctl status unbound
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-09-27 08:48:11 +0545; 50s ago
     Docs: man:unbound(8)
  Process: 500 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 541 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
 Main PID: 571 (unbound)
    Tasks: 1 (limit: 2065)
   CGroup: /system.slice/unbound.service
           └─571 /usr/sbin/unbound -d

Sep 27 08:48:10 raspberrypi systemd[1]: Starting Unbound DNS server...
Sep 27 08:48:11 raspberrypi package-helper[541]: /var/lib/unbound/root.key has content
Sep 27 08:48:11 raspberrypi package-helper[541]: fail: the anchor is NOT ok and could not be fixed
Sep 27 08:48:11 raspberrypi unbound[571]: [571:0] info: start of service (unbound 1.9.0).
Sep 27 08:48:11 raspberrypi systemd[1]: Started Unbound DNS server.

pi@raspberrypi:~ $ sudo unbound-anchor

pi@raspberrypi:~ $ sudo service unbound restart

pi@raspberrypi:~ $ systemctl status unbound
● unbound.service - Unbound DNS server
   Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-09-27 08:49:30 +0545; 19s ago
     Docs: man:unbound(8)
  Process: 857 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
  Process: 860 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
 Main PID: 864 (unbound)
    Tasks: 1 (limit: 2065)
   CGroup: /system.slice/unbound.service
           └─864 /usr/sbin/unbound -d

Sep 27 08:49:29 raspberrypi systemd[1]: Starting Unbound DNS server...
Sep 27 08:49:30 raspberrypi package-helper[860]: /var/lib/unbound/root.key has content
Sep 27 08:49:30 raspberrypi package-helper[860]: success: the anchor is ok
Sep 27 08:49:30 raspberrypi unbound[864]: [864:0] info: start of service (unbound 1.9.0).
Sep 27 08:49:30 raspberrypi systemd[1]: Started Unbound DNS server.
pi@raspberrypi:~ $

Expected Behaviour:

Unbound should work with the anchor

Actual Behaviour:

raspberrypi package-helper[541]: fail: the anchor is NOT ok and could not be fixed

Debug Token:

N/A

i was able to find a similar bug report on debian bugtracker about this.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667740

This is related solely to unbound, not to Pi-hole.

That said, seeing an "anchor is NOT ok" message would be quite normal during reboots, especially for RPis (mine is showing that, too).
Trying to check unbound's DNSSEC root anchor is bound to fail without your network being up or established internet connectivity or accurate time information. The latter is problematic for RPis, as their lack of an RTC means they rely entirely on NTP to acquire that time information from the internet.

In all likelihood, such a root anchor check failure will not impact unbound's capability to verify DNSSEC: The DNS root trust anchors are not updated very often (last update was in 2018). Your local root.key would still be valid.

If DNSSEC would indeed fail for you directly after a reboot, that wouldn't be because of that failed anchor check. Rather, I'd suspect that to be another symptom of the same root cause, i.e most likely an inaccurate time.
You should see DNSSEC resolution return after a successfully completed time-sync.

But I'm not an unbound pro, so if your issue would still persist after that, consulting unbound support may improve your chances for resolving it.