On 29/11/25 5:57, Ondřej Surý wrote:
On 29. 11. 2025, at 4:35, Jesus Cea <[email protected]> wrote: DLZ simply can not be used as RPZThis. 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 _/_/ _/_/_/ _/_/_/ [email protected] - https://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:[email protected] _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
OpenPGP_signature
Description: OpenPGP digital signature
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
