Environment
• Pi-hole Core: 6.4.3
• Pi-hole Web: 6.6
• Pi-hole FTL: 6.7
• Hardware: Raspberry Pi 5
• OS: Raspberry Pi OS Bookworm
• Router: AVM FRITZ!Box 7590
• FRITZ!OS: 8.25
Configuration
Conditional Forwarding:
• Enabled
• Router/DNS: 192.168.171.1
• Network: 192.168.171.0/24
• Local domain: fritz.box
DNSSEC: Enabled
Summary
Forward DNS lookups work correctly, but reverse (PTR) lookups fail with SERVFAIL when DNSSEC is enabled. Disabling only DNSSEC immediately restores correct reverse lookups.
Reproduction
Forward lookup:
dig @127.0.0.1 WoZi-EckeRGB.fritz.box
Result:
Correct A record returned.
Reverse lookup:
dig @127.0.0.1 -x 192.168.171.45
Result:
status: SERVFAIL
Direct query to the FRITZ!Box:
dig @192.168.171.1 -x 192.168.171.45
Result:
PTR WoZi-EckeRGB.fritz.box.
Disable only DNSSEC in Pi-hole:
Settings → DNS → Disable DNSSEC
Run again:
dig @127.0.0.1 -x 192.168.171.45
Result:
status: NOERROR PTR WoZi-EckeRGB.fritz.box.
LanScan (macOS) and Network Scanner (iPhone) immediately begin displaying all hostnames again.
Re-enable DNSSEC:
dig +dnssec @127.0.0.1 -x 192.168.171.45
Result:
status: SERVFAIL EDE: 0 (Other)
Additional observations
• Forward lookups are never affected.
• The problem only affects reverse PTR lookups.
• The behavior is fully reproducible by enabling/disabling DNSSEC.
• No other configuration changes are required.
Debug information
Pi-hole debug token:
https://tricorder.pi-hole.net/CNIWYf6f/
(Debug logs are available for 48 hours after upload.)
Expected behavior
Conditional Forwarding should correctly return local PTR records from the FRITZ!Box regardless of whether DNSSEC is enabled.
Actual behavior
With DNSSEC enabled, Pi-hole returns SERVFAIL for local reverse lookups while the FRITZ!Box itself returns the correct PTR record.
Thank you for looking into this issue.
Hello @AntonJouri
i faced the same situation.
After i looked into the knowledge base of Fritz i found out that:
DNS queries are not resolved via the FRITZ!Box if the devices use a DNSSEC validation (i.e. an authenticity validation of DNS entries for a domain).
The problem affects both their own local DNS servers in the home network (for example Pi-hole, Bind9), which are announced via the FRITZ!Box DHCP server, and connector in doctors' offices and pharmacies (for example Gematik, secunet).
So i've decided to go without DNSSEC for my local network.
I hope this information helps you.
Best regards, A7GPS0
Thank you for the information and the AVM knowledge base article.
This seems to explain the observed behaviour.
However, in my case the problem specifically affects reverse (PTR) lookups returned by the FRITZ!Box via Conditional Forwarding.
Do you consider this to be the same limitation described by AVM, or should Pi-hole ideally treat locally forwarded reverse lookups differently when DNSSEC is enabled?
Got an idea from below one:
What if you add below dnsmasq directive?
trust-anchor=171.168.192.in-addr.arpa.
EDIT: For example:
$ sudo pihole-FTL --config misc.dnsmasq_lines
[]
$ sudo pihole-FTL --config misc.dnsmasq_lines '["trust-anchor=171.168.192.in-addr.arpa."]'
[ trust-anchor=171.168.192.in-addr.arpa. ]
$ sudo pihole-FTL --config misc.dnsmasq_lines
[ trust-anchor=171.168.192.in-addr.arpa. ]
You can also find that "Expert" setting on the webGUI.
Probably not gonna work but worth a try 
I was thinking about something like that too, but then just entered in the Conditional Forwarding configuration, however since I never use it I have no idea if that actually works...
Private reverse zones lack public DNSSEC chains, so this is the AVM limitation manifesting specifically on those records. Forward lookups succeed because the domain is explicitly forwarded, whereas the reverse zone is computed implicitly and hits standard validation. Reverse lookups for local infrastructure should indeed be treated differently than public queries when conditional forwarding is active.