I can confirm this is happening with my router running FritzOS 7.56 when using the FritzBox as Pi-hole's only upstream and DNSSEC validation enabled.
I can't make any statements whether this worked with previous versions, though, as I am usually using unbound as Pi-hole's upstream.
$ dig heise.de
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Raspbian <<>> heise.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43661
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 0c ("..")
;; QUESTION SECTION:
;heise.de. IN A
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 06 09:09:11 CEST 2023
;; MSG SIZE rcvd: 43
EDE response code 0c (or 12 decimal) translates to NSEC(3) missing .
Using BIND9's delv to verify DNSSEC validation via the Fritzbox at 192.168.178.1 reveals the reason for that:
$ delv heise.de @192.168.178.1
;; DNS format error from 192.168.178.1#53 resolving de/DS: unrelated SOA fritz.box in de authority section
;; DNS format error from 192.168.178.1#53 resolving box/DS: unrelated SOA fritz.box in box authority section
;; no valid RRSIG resolving 'box/DS/IN': 192.168.178.1#53
;; no valid RRSIG resolving 'de/DS/IN': 192.168.178.1#53
;; no valid DS resolving 'heise.de/A/IN': 192.168.178.1#53
;; resolution failed: no valid DS
Obviously, the FritzBox is wrongly inserting its own SOA information into DNSSEC replies, causing DNSSEC validation to fail.
To verify, a public upstream would return:
$ delv heise.de @9.9.9.9
; unsigned answer
heise.de. 3200171710 IN A 193.99.144.80
This has to be fixed by Fritzbox manufacturer AVM.
You should try to reproduce similar output on your installation and file a support request with that information at FRITZ!Box Supportanfrage.
In the meantime, you could switch to a public DNS resolver with DNSSEC support as Pi-hole's upstream in combination with Conditional Forwarding to your FB enabled in Pi-hole. Note that DNSSEC validation is skipped for CF.
Alternatively, you could consider to disable DNSSEC validation in Pi-hole, but that would obviously mean that you would not know whether your DNS replies are authentic and can be trusted.