and then an RPZ zone defined as:
'''
rpz:
name: "rpz.test.zone"
zonefile: "/var/unbound/etc/zones/rpz/rpz.test.zone"
rpz-action-override: nxdomain
rpz-log: yes
rpz-log-name: "rpz.test"
tags: "tag1 tag2 test-client"
'''
containing a line like "*.test.com CNAME .", I correctly get
an NXDOMAIN when querying "hello.test.com" when _no_ views are
enabled. However, if I throw views into the mix, then I am seeing
"hello.test.com" actually resolve. Here are my view definitions:
'''
access-control-view: 10.0.0.1/32 test-client
Note that querying "test.internal" from 10.0.0.1 returns the correct
A record, but querying anything under "rpz.test.zone" seems to bypass
RPZ. Is this intended behavior, am I not supposed to mix views and
RPZ, or is there perhaps a bug? Would be interested if anyone can
reproduce or if I've messed this up on my end. I have not yet turned
up verbosity to do any deeper digging, but would be happy to do so, and
I am willing/able to compile/test any fixes if there is indeed a bug.
From a quick test here locally (1.22.0) the tagged client does get the view local-data and also gets RPZ filtering applied.
The minimal configuration I used is:
'''
server:
module-config: "respip validator iterator"
define-tag: "test-client"
access-control-tag: 127.0.0.0/8 "test-client"
access-control-view: 127.0.0.0/8 "test-client"
If the above does not work for you a couple of pointers:
- Is the incoming traffic using the expected 10.0.0.1 IP?
- Are you using proxy-protocol-port?
- Other configuration that interferes with the above? Mainly for the
access-control part?
- Maybe the content of the RPZ? Try using just a single record for
testing (you still need to SOA record as well).
Thank you very much for the suggestions and for being able to do a
quick test to confirm the functionality on your end. I just reviewed
your configuration, tried again, and things do seem to be working
as expected!
It's possible I left off the "test-client" tag within the RPZ zone
definition, but then unwittingly added it as I typed out the email
(after I had reset back to my "known-working" state). Apologies for
barking up the wrong tree! Time to get some more sleep before trying
to change my Unbound configuration :-).
Actually, I did get similar behavior again and was hoping to get
further clarification. It's very likely just a misunderstanding on
my behalf of how tags and views work!
When I define tags exactly like so (note: no test-client tag this
time):
'''
define-tag: "all-subnet-clients"
access-control-tag: 10.0.0.0/24 "all-subnet-clients"
'''
and then have views defined like so:
'''
access-control-view: 10.0.0.1/32 test-client
I do get back "10.0.0.1" when querying "test.internal" from 10.0.0.1,
as expected. However, when RPZ is defined as:
'''
rpz:
name: "rpz.test.zone"
zonefile: "/var/unbound/etc/zones/rpz/rpz.test.zone"
rpz-action-override: nxdomain
rpz-log: yes
rpz-log-name: "rpz.test"
tags: "all-subnet-clients"
'''
and containing a line like "*.test.com CNAME ." in rpz.test.zone, I
was expecting a query for "hello.test.com" from 10.0.0.1 to get the
"all-subnet-clients" tag and return NXDOMAIN, but instead it seems
to bypass tagged RPZ and recurse. Is that intended behavior? Please
note that I do see _untagged_ (global) RPZ zones being successfully
applied to queries coming from 10.0.0.1.
If I explicitly define a "test-client" tag (in addition to the
"all-subnet-clients" tag), as in the configuration you kindly sent
yesterday:
'''
define-tag: "test-client"
access-control-tag: 10.0.0.1/32 "test-client"
'''
and then update the RPZ tags definition:
'''
rpz:
...
tags: "all-subnet-clients test-client"
...
'''
I get exactly what I wanted: an A query from 10.0.0.1 for
"test.internal" resolves to 10.0.0.1, and an A query from 10.0.0.1
for "hello.test.com" returns NXDOMAIN. I was then able to reproduce
the "bypass tagged RPZ behavior" by removing all the test-client tag
definitions (reproduced twice for good measure before writing to the
list this time ).
Each prefix entry creates an access control item that holds the relevant tag and view information.
So,
10.0.0.0/24 is one entry with the tag "all-subnet-clients" and no view.
10.0.0.1/32 is another entry with no tags and the "test-client" view.
When a query comes in it will be assigned the most specific access control item.
10.0.0.1 will get no tags and the "test-client" view.
10.0.0.2 will get the "all-subnet-clients" tag and no view.
There is no logic to try and spread, in your example, the less specific tag/view information to most specific items.
I guess that would also not allow for overrides for most specific networks.
I haven't tried to reproduce anything this time so if I missed something let me know.
Each prefix entry creates an access control item that holds the relevant
tag and view information.
When a query comes in it will be assigned the most specific access
control item.
There is no logic to try and spread, in your example, the less specific
tag/view information to most specific items.
I guess that would also not allow for overrides for most specific networks.
Aha, thank you for the great explanation! That makes perfect sense
and is consistent with the behavior I observed.
I should be able to adapt my use-cases with this new knowledge.
).