Using a DLZ as RPZ?

[Jesus Cea]

On 29/11/25 5:57, Ondřej Surý wrote:
> 
>> On 29. 11. 2025, at 4:35, Jesus Cea <jcea at jcea.es> wrote:
>>
>> DLZ simply can not be used as RPZ
> 
> This. But you can probably easily rewrite your DLZ into a plugin that has access to similar places as RPZ.

That was the first thing I tried, but there is zero documentation and 
only a code example (filter-aaaa.c). I have invested quite a few hours 
trying to do what I want to do. Being able to reply to a query with 
NXDOMAIN was quite easy, but I have invested quite a few hours trying to 
learn enough details about the bind internal arcane code to cope enough 
with rdata/rdatalist/rdataset bind intricate details to be able to put a 
"fake" SOA in the ADDITIONAL section of the NXDOMAIN reply for allowing 
negative caching. If somebody could help there...

> If this works well, would you want to contribute this as an open-source?

I would share the code to interface to bind using the plugin/hooks api, 
yes. Then anybody can do their own "is this domain filtered or not" 
logic. Sharing that part would be difficult because it is attached to my 
infrastructure (Kafka, cuckoo filtering and cuckoo hashes building, no 
lock structures, etc, replication, etc). But that is "easy" compared 
with being able to understand how bind works internally enough to 
manipulate its reply structures.

I have even considered to create a fake reply byte by byte to avoid to 
fight the undocumented internal bind functions...

Some help there would be useful.

As I said, I managed to reply with NXDOMAIN early in the query 
processing in order to simulate a RPZ hit, but that reply has no SOA in 
AUTHORITY or ADDITIONAL. A normal RPZ hit has a SOA in the ADDITIONAL 
section in order to allow for negative caching, as documented in RFC 
2308. I am stuck there, and I am pretty sure this could be done in 20 
lines of code, but I has been not able to do that yet. I am now trying 
to understand enough about bind internals, but it is not easy.

Some help appreciated. Functional source code for future poor souls to 
skip them the pain in exchange.

I have found "dns_soa_buildrdata()" function, but I was not able to 
insert that in the DNS reply yet.

Ideally that SOA could be cached and reused for every reply for RPZ 
hits, but maybe could be easier to redo it each time because memory 
management. I am not sure yet.

That SOA attachment is the only missing link. Help!.

PS: Of course, doing this will break DNSSEC. That is a given.

-- 
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/20251202/42454e2f/attachment.sig>