An experimental RPZ plugin (was Re: Using a DLZ as RPZ?)

[Jesus Cea]

On 2/12/25 10:26, Petr Špaček wrote:
> On 02. 12. 25 0:11, Jesus Cea wrote:
>> "fake" SOA in the ADDITIONAL section of the NXDOMAIN reply for 
>> allowing negative caching.
> 
> FTR SOA in ADDITIONAL section is only informative - basically saying 
> "this RPZ blocked it".

The SOA in ADDITIONAL in a NXDOMAIN response allow for negative caching, 
as described in RFC 2308. The RFC talks about AUTHORITATIVE section 
because it is the reply that the authoritative server must provide in 
order to allow negative caching.

In a RPZ hit, the NXDOMAIN is not authoritative, it is a "hijacked" 
reply. Bind inserts a SOA in the ADDITIONAL reply to allow negative 
caching, but doesn't pretend to be the authoritative server for that name.

> For negative caching you would have to put SOA into AUTHORITY section - 
> with correct zone name as SOA RR owner. Using random name might cause 
> retry storm from clients (if particular client implementation checks 
> things).

I just cloning what Bind is actually doing.

Bind reply to a domain hitting the RPZ:

"""
[jcea at tmz1-dns ~]$ dig @127.0.0.1 xindajiema.info

; <<>> DiG 9.18.41 <<>> @127.0.0.1 xindajiema.info
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38118
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 2079c1a689e2825c0100000069310d39290f22167185e964 (good)
;; QUESTION SECTION:
;xindajiema.info.               IN      A

;; ADDITIONAL SECTION:
rpz.local.              86400   IN      SOA     localhost. 
root.localhost. 7658870 900 300 2419200 86400

;; Query time: 136 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Dec 04 05:25:29 CET 2025
;; MSG SIZE  rcvd: 131
"""

Notice the NXDOMAIN and the SOA in the ADDITIONAL section, reporting 
what RPZ zone was hit. This is current bind behaviour.

Now my experimental RPZ plugin. "datos.jcea.es" is a server that 
actually exists, but I have added it to my private RPZ to validate my 
implementation:

"""
[jcea at tmz1-master /home]$ dig @127.0.0.1 datos.jcea.es

; <<>> DiG 9.18.42 <<>> @127.0.0.1 datos.jcea.es
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60245
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 27c90ca63ac2893b0100000069310dc0cef4eae9feed3c2b (good)
;; QUESTION SECTION:
;datos.jcea.es.                 IN      A

;; ADDITIONAL SECTION:
rpz.                    300     IN      SOA     rpz-fake.XXX.es. 
root.rpz-fake.XXX.es. 1 3600 1800 604800 300

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Dec 04 05:27:44 CET 2025
;; MSG SIZE  rcvd: 132
"""

Notice I am replying in the same line than Bind: NXDOMAIN, SOA in the 
additional section and the zone name is the RPZ hit.

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - https://www.jcea.es/    _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20251205/4cfe0677/attachment.sig>