Reverse PTR forwarding in NextDNS CLI

I'm a really happy NextDNS paying customer, to the point that I've adopted NextDNS into my core network stack to maximize the benefits. I’ve successfully implemented a hybrid NextDNS CLI + Unbound deployment on OPNsense and overall it’s working very well. I've got both local DNS authority (with Unbound) and per-device visibility in NextDNS analytics, which was my goal.

However, I appear to have found a possible issue in which reverse DNS (PTR) forwarding is behaving inconsistently.

Environment:

• OPNsense 26.1.x
• NextDNS CLI running directly on firewall
• Unbound DNS running locally on alternate port (53535)
• Local authoritative DNS and PTR records managed by Unbound
• NextDNS CLI serving as primary resolver on :53

Forward lookups work perfectly through split-horizon forwarding.

Example config:

forwarder joesnetwork.arpa.=192.168.1.1:53535

Result:

• Queries to NextDNS CLI on :53 correctly forward to Unbound
• Local A records resolve properly

However, reverse PTR forwarding does not appear to behave the same way.

Example config:

forwarder 1.168.192.in-addr.arpa.=192.168.1.1:53535

Direct query to Unbound DNS:

dig @192.168.1.1 -p 53535 -x 192.168.1.30

Expected PTR returned:

garage-reolink-cam.joesnetwork.arpa.

Same query through NextDNS CLI:

dig @192.168.1.1 -x 192.168.1.30

Result:

NXDOMAIN

I tested several variations of forwarder entires in the NextDNS CLI config:

• specific reverse zones
• broader reverse zones
• trailing dots
• leading-dot syntax
• full in-addr.arpa forwarding

None consistently forwarded PTR requests to Unbound.

Interestingly:

• some reverse lookups return mDNS-derived .local responses
• others return NXDOMAIN
• direct Unbound queries consistently work correctly

This suggests NextDNS CLI may not be forwarding PTR lookups through split-horizon forwarders the same way it handles forward lookup zones.

Expected behavior:
PTR requests matching configured reverse zones should forward identically to A/AAAA requests.

The desired outcome is enterprise-style split-horizon DNS with local PTR-derived hostname enrichment preserved inside NextDNS analytics/logging. 

Behavior has been reproduced consistently across multiple restart/reconfiguration attempts.

I would love to know whether:

1. This is expected behavior
2. PTR forwarding support is incomplete
3. There’s a syntax/configuration nuance I may be missing
4. This could be considered for enhancement/fix

Happy to provide additional logs or testing details if useful.