DNSSECしたサイトのドメイン名検証が失敗する
参考URL：https://support.biglobe.ne.jp/settei/setuzoku/other/serverinfo.html
読むべきポイントは、DNS サーバの大きな字形の下にある小さな字形の文章
- ※DNSSECを導入したサイトの検証をするには、DNSサーバの設定を以下のとおり変更してください。
local-unboundのクエリ転送先（forward先、DNS クエリ転送設定）を変更したら、数日間DNS Server Failでアクセス禁止状態になっていたFreeBSD.orgのウェブサイトにアクセスできるようになりました。
ついでに「blog.nic.ad.jp」にもアクセスできるようになりました。
失敗していた設定ってどんなんだったん？
クエリ転送先をホームゲートウェイにしていました。 NTT 回線（いまだとドコモ光看板で内側は従来通りのフレッツ網？）のレンタルホームゲートウェイです。
デフォルト状態で利用しているので、初期値通り「192.168.1.1/32」に鎮座しています。
ここにクエリ転送していました。 結果的にリゾルバを二回挟むような格好ですが、一応DNS を引けていました。
推察される原因
参考URL を見る通り、敢えて二つのIPアドレス（DNS キャッシュサーバ）を使って運用しています。
しかし、ここ最近（2020年1月頃から）一部のサイトに対してアクセス不能に（＝正確には、DNS レコードを引けなく）なりました。
それ以前では、自宅の内部LAN に立てているDNS リゾルバでDNSSECを有効（＝トラストアンカー機能を活性）にすると引けなくなっていました。
と言うことは、恐らく「既定で広報しているDNS キャッシュサーバで何かが行われた」か「FreeBSD 側のlocal_unboundが既定の動作を変更した」のどちらかに思われます。
まとめ
取り敢えず、動いたから原因分析を深く追求する必要はないかなって思います。
気になるのは、FreeBSD 側は、トラストアンカーを参照していないのに、DNSSEC対応のbiglobe側キャッシュサーバを参照するとServer Failが発生しなかった点です。
つまり「local_unboundがトラストアンカーを活性にせずともDNSSEC検証を行っている」ように感じます。