RPZ tags aren't matched with interface-tag

[tomushkin]

Describe the bug

According to the documentation RPZ tags are also matched against interface tags:

tags need to be matched either with the client IP prefix using access-control-tag: or the clients on a listening interface using interface-tag:

However, only access-control-tags appear to be applied.

To reproduce

Considering the configuration:

server:
    module-config: "respip validator iterator"
    interface: lo@5301
    interface: lo@5302
    define-tag: "malware social"
    interface-tag: lo@5301 "malware"
    interface-tag: lo@5302 "social"
rpz:
    name: malware.rpz.example.com
    zonefile: malware.rpz.example.com
    tags: "malware"
rpz:
    name: social.rpz.example.com
    zonefile: social.rpz.example.com
    tags: "social"

Both unbound v1.20.0 and v1.17.1 respond with the malware RPZ regardless of the interface used, while latest git (d43760a8cd7d01f59fd73bf7edbf983903d8a142) uses no RPZ.

Expected behavior

Queries on port 5301 should be replied with "malware" RPZ, port 5302 with "social".

System:

• Unbound version: 1.20.0
• OS: Arch Linux
• unbound -V output:

  
  Version 1.20.0

Configure line: --prefix=/usr --sysconfdir=/etc --localstatedir=/var --sbindir=/usr/bin --disable-rpath --enable-dnscrypt --enable-dnstap --enable-pie --enable-relro-now --enable-subnet --enable-systemd --enable-tfo-client --enable-tfo-server --enable-cachedb --with-libhiredis --with-conf-file=/etc/unbound/unbound.conf --with-pidfile=/run/unbound.pid --with-rootkey-file=/etc/trusted-key.key --with-libevent --with-libnghttp2 --with-pyunbound Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.3.1 4 Jun 2024 Linked modules: dns64 cachedb subnetcache respip validator iterator DNSCrypt feature available 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

[gthess]

I added extra RPZ tests in the interface* options test with https://github.com/NLnetLabs/unbound/commit/51425b23884a368a2d8471b11fa47dc2d6fa75ed; these are fine.

I believe this issue has to do with the implicit access-control imposed by Unbound. Does the lo interface include the 127.0.0.0/8 range? In that case incoming clients will match the access-control directive and not the interface directive. It is somewhat mentioned in the documentation but not clearly. Let me see how it can be updated.

[gthess]

And btw latest git contains some rpz tag fixes and is functioning correctly because technically there is no rpz tag for a 127.0.0.0/8 client configured; Unbound's implicit access-control configuration shadows the interface* configuration.

[tomushkin]

In production we use a different subnet but still access it via access-control. I confirm that in 1.20.1, by following testdata configuration and replacing access-control with interface-action: allow the RPZs are applied as expected on each interface.

Thanks for your time and clarifications — this can be closed as it appears not to be a bug but rather an unobvious exclusivity between access-control, interface-action and associated tags.