Describe the bug
First of, this is 100% related to this comment #935 (comment)

To reproduce
Steps to reproduce the behaviour:

1. add a number of rpz zones/rules
2. in one zone you hold your own local rules, not imported from third party
3. You would expect your own rules to supersede any other rules that might be imported.
4. dig any PASSTRU record and receive NXDOMAIN

Expected behaviour
RPZ PASTHRU supersedes other rules, or having a weight system for the individual zones, whereof weight of null/zero/0 are weighting the highest as 0 comes first in line of the IT universe.

System:

• Unbound version:
• OS: Debian 12.6
• /usr/sbin/unbound -V output:

  Version 1.17.1
  Configure line: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --enable-tfo-server
    Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.13 30 Jan 2024
    Linked modules: dns64 python subnetcache respip validator iterator
   TCP Fastopen feature available
   BSD licensed, see LICENSE in source package for details.
   Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
  

Additional information
Parsed from #395

I actually have a similar situation where is seems like any "Blocking" rule super seeds "permissive" rules like the passtrhu.

There can be a numerous good arguments for why this is, however, in my case I maintenance a local rpz zone that differs from my projects records *.mypdns.cloud", in my local RPZ zone I have a number of paastru` records for e.g. GitHub like these

avatars.githubusercontent.com.blacklist.matrix.lan,CNAME,rpz-passthru
private-user-images.githubusercontent.com.blacklist.matrix.lan,CNAME,rpz-passthru

Whereas the @matrix project have the following records

raw.githubusercontent.com.whitelist.mypdns.cloud,CNAME,rpz-passthru
*.githubusercontent.com.malicious.mypdns.cloud,CNAME,.
*.githubusercontent.com.tracking.mypdns.cloud,CNAME,.

Expected behaviour is to get the PASSTRUE = the IP for both avatars- private-user-images.githubusercontent.com

While the log for sure show what actually happens.

Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: 127.0.0.1 avatars.githubusercontent.com. A IN
Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: rpz: applied [malicious policy] *.githubusercontent.com. rpz-nxdomain 127.0.0.1@36385 avatars.githubusercontent.com. A IN
Jul 12 19:28:35 vision unbound[104053]: [104053:5] info: 127.0.0.1 avatars.githubusercontent.com. A IN NXDOMAIN 0.000000 1 58

The question is now, how can the expected output be accommodated by using the RPZ standard rules? is this a request for a weight system, from where a list with the weight of 0 supersedes other lists? (As Zero is the first number in the IT universe and stays first in line)