It would seem that your pihole2.lab.xxx (.8) is desperate for getting the correct time from a set of time servers at *.pool.ntp.org.
Since that is likely running on an RPi, that may suggest that RPi's clock may be (or have been) out of sync.
Then your pihole2 RPi would try to sync time with 1.us.pool.ntp.org, but since unbound is employing DNSSEC, it would not be able to resolve that domain (nor any other public domains) - for lack of precise time information.
There are several ways to address this, e.g. you could consider to purchase and install an RTC, or to forward requests for us.pool.ntp.org to a public DNS resolver or your router, or to supply your router as a time server for that Raspberry Pi OS machine in /etc/systemd/timesyncd.conf (provided your router can be configured to act as a time server).
We've only recently discussed those and other options in Failing lookups after power outage DNSSEC - #20 by DL6ER.
Not likely to be related, but your debug log also shows that your Pi-hole is configured for eth0, which doesn't exist on your system. Its Ethernet interface is labeled enxb827eb09ecfe instead.
This may be a side effect of a recent upgrade to Bullseye, which may have switched your OS to use predictable names once again.
A default Pi-hole would then fail to receive DNS requests, but in your case, you have changed Pi-hole's listening behaviour to Listen on all..., allow all origins (presumably to cater for Wireguard connections, as wg0 would suggest).
While your pihole2 is still responsive, the same may not be true for another Pi-hole with an Interface listening behaviour tied strictly to a specific interface.
To address this, you could either run pihole -r with Reconfigure and choose the correct network interface, or disable predictable interface names via an Advanced Option in raspi-config.