Changes in RPZ behaviour between versions

[Paulo Cáceres]

Hi list,
I'm writing this email to ask if the changes I detected in bind
behaviour are as expected or I'm facing some unexpected behaviour.

I searched for this, without success, so now I'm posting this issue I
found between bind versions, 9.14.5 and 9.16.3.

I have an old testing machine running bind 9.14.5 with RPZ zones. The
first one (rpz1) is working as an whitelist and the second one (rpz2)
is automatic populated, as you can check in config bellow:

response-policy {
zone "rpz1";
zone "rpz2";
} qname-wait-recurse no break-dnssec yes;

For example, in rpz1 zone I have something like this:
test.com IN CNAME rpz-passthru.
*.test.com IN CNAME rpz-passthru.

And, for example, in rpz2 zone, which are automatic populated, at same
point may have:
tst.test.com IN CNAME secure.test.
*.tst.test.com IN CNAME secure.test.

when this config is running on the machine with bind 9.14.5, if you
query it for tst.test.com, it simply passthru it because it match on
the rpz1 zone (*.test.com), acting as whitelist as expected.
If I run the same query on a new machine with bind 9.16.3, running the
same config, it will rewrite it to secure.test, matching it in the rpz2
zone.

Is this second result (on the last version) the expected behaviour?
What version are deviating from the expected one?

Best regards,
Paulo

[Daniel Stirnimann]

Hello Paulo,

I noticed the same some time ago and made an issue on gitlab.isc.org:

https://gitlab.isc.org/isc-projects/bind9/-/issues/1619

For your information, you cannot whitelist with wildcards anymore
starting from bind 9.14.6 and newer.

What still works is if the blacklist contains a wildcard then you can
whitelist this with the same wildcard. For example, you can add the
following to rpz1:

*.tst.test.com IN CNAME rpz-passthru.


Daniel

Post by Paulo Cáceres
Hi list,
I'm writing this email to ask if the changes I detected in bind
behaviour are as expected or I'm facing some unexpected behaviour.
I searched for this, without success, so now I'm posting this issue I
found between bind versions, 9.14.5 and 9.16.3.
I have an old testing machine running bind 9.14.5 with RPZ zones. The
first one (rpz1) is working as an whitelist and the second one (rpz2) is
response-policy {
                zone "rpz1";
                zone "rpz2";
        } qname-wait-recurse no break-dnssec yes;
test.com              IN CNAME        rpz-passthru.
*.test.com            IN CNAME        rpz-passthru.
And, for example, in rpz2 zone, which are automatic populated, at same
tst.test.com IN CNAME        secure.test.
*.tst.test.com       IN CNAME        secure.test.
when this config is running on the machine with bind 9.14.5, if you
query it for tst.test.com, it simply passthru it because it match on the
rpz1 zone (*.test.com), acting as whitelist as expected. 
If I run the same query on a new machine with bind 9.16.3, running the
same config, it will rewrite it to secure.test, matching it in the rpz2
zone.
Is this second result (on the last version) the expected behaviour? What
version are deviating from the expected one?
Best regards,
Paulo
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

[Paulo Cáceres]

Hello Daniel,thanks for your response.
I also noticed that if tst.test.com didn't exist on rpz2, it simply
match on rpz1 in *.test.com entry, so for me it was like some bug. This
was why I posted here to check if someone else experienced the same
behaviour and it if it was not some kind of expected change into bind.
This problem with wildcards will give a lots of work to who have rpz
zones updated automatically, so I hope it can go back to what it was.
Thanks again and I hope that someone took your open issue ;).
Regards,Paulo

Post by Daniel Stirnimann
Hello Paulo,
https://gitlab.isc.org/isc-projects/bind9/-/issues/1619
For your information, you cannot whitelist with wildcards
anymorestarting from bind 9.14.6 and newer.
What still works is if the blacklist contains a wildcard then you
canwhitelist this with the same wildcard. For example, you can add
*.tst.test.com IN CNAME rpz-passthru.
Daniel
On 02.06.20 13:58, Paulo Cáceres wrote:Hi list,I'm writing this email
to ask if the changes I detected in bindbehaviour are as expected or
I'm facing some unexpected behaviour.
I searched for this, without success, so now I'm posting this issue
Ifound between bind versions, 9.14.5 and 9.16.3.
I have an old testing machine running bind 9.14.5 with RPZ zones.
Thefirst one (rpz1) is working as an whitelist and the second one
response-policy { zone "rpz1"; zone
"rpz2"; } qname-wait-recurse no break-dnssec yes;
For example, in rpz1 zone I have something like
this:test.com IN CNAME rpz-
passthru.*.test.com IN CNAME rpz-passthru.
And, for example, in rpz2 zone, which are automatic populated, at
samepoint may have:tst.test.com IN
CNAME secure.test.*.tst.test.com IN
CNAME secure.test.
when this config is running on the machine with bind 9.14.5, if
youquery it for tst.test.com, it simply passthru it because it match
on therpz1 zone (*.test.com), acting as whitelist as expected. If I
run the same query on a new machine with bind 9.16.3, running thesame
config, it will rewrite it to secure.test, matching it in the
rpz2zone.
Is this second result (on the last version) the expected behaviour?
Whatversion are deviating from the expected one?
Best regards,Paulo
_______________________________________________Please visit
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.

--
Paulo Cáceres
SIN-Área de Sistemas de Informação


Escritório/Sede: Fábrica de Água de Alcântara, Avenida de Ceuta | 1300-254 LISBOA | Tel: [phone] | http://www.aguasdotejoatlantico.adp.pt


Tenha uma EcoAtitude. Imprima este e-mail apenas se necessário.Esta mensagem e os ficheiros anexos podem conter informação confidencial ou interna. Se, por engano, receber esta mensagem, solicita-se que informe de imediato o remetente e que elimine a mensagem e ficheiros anexos sem os reproduzir.
This message and any files herewith attached may contain confidential or internal information. If you receive this message in error, please notify us immediately and delete this message and any files attached without copying them in any way.