CoreDNS (rexdns) converting Unbound NXDOMAIN responses to SERVFAIL on 26.07_3

SilentJ

I'm testing Nexus CoreDNS with Unbound as its only upstream, but CoreDNS appears to be converting Unbound's NXDOMAIN responses into SERVFAIL.

Design

Clients → CoreDNS:53 → Unbound 127.0.0.1:5353 → Quad9 and Cloudflare (DoT)

System details

pfSense Plus 26.07
pfSense-pkg-Nexus 26.07_3
Nexus build: 0fd1915da462e197aaa12820fc51ec2750b37226

All services are running and listening on the expected ports:

CoreDNS (rexdns): 53
Unbound: 5353
Nexus: 8443

The active generated CoreDNS configuration is minimal:

(rexdns) {
    rexdns {
        default 127.0.0.1:5353
    }
}

. {
    bind [local interfaces]
    import rexdns
}

No blocklists are assigned to the active CoreDNS group, and ZTE and ThreatGate are both disabled.

Reproduction

Querying Unbound directly for a nonexistent name:

dig @127.0.0.1 -p 5353 rexdns-negative-test-20260922-01.example A +dnssec +noall +comments

status: NXDOMAIN
flags: qr rd ra ad
AUTHORITY: 6

The same query through CoreDNS:

dig @<router IP> rexdns-negative-test-20260922-01.example A +dnssec +noall +comments

status: SERVFAIL
flags: qr rd
WARNING: recursion requested but not available
AUTHORITY: 0

This reproduces consistently with multiple distinct nonexistent names.

Unbound's response includes the ra flag and six authority records, while the CoreDNS response has neither. This suggests CoreDNS is generating the SERVFAIL itself rather than passing Unbound's response through.

Control tests (behaving as expected)

For comparison, these queries through CoreDNS return the expected results, which confirms that normal resolution and DNSSEC validation are working.

A valid domain resolves normally:

dig @<router IP> cloudflare.com A

status: NOERROR
flags: qr rd ra
AUTHORITY: 0

A deliberately broken DNSSEC domain fails validation, as it should:

dig @<router IP> dnssec-failed.org A +dnssec +noall +comments

status: SERVFAIL
flags: qr rd
WARNING: recursion requested but not available
AUTHORITY: 0

Conclusion

I'm relatively new to this, but it seems that since Unbound returns a DNSSEC-authenticated NXDOMAIN for the same query, the problem appears to be in the CoreDNS (rexdns) forwarding path rather than in Unbound, DNSSEC validation, the public upstream resolvers, or a blocklist.

Questions

Is this a known rexdns issue in 26.07_3?
Is there a supported workaround other than bypassing CoreDNS and moving Unbound back to port 53?