Re: Custom DNS Filtering Plugin in BIND 9

[Grant Taylor via bind-users]

On 3/19/25 10:02 AM, Ondřej Surý wrote:
Thinking aloud - perhaps, we can extend the plugin API (and RPZ) in a 
way to add the classification to the message processing and then the RPZ 
processing could read the classification and take an action?


This sounds like my understanding of what the Response Policy Service 
(RPS) is supposed to achieve.


"The DNS Response Policy Service (DNSRPS) API, is a mechanism to allow 
named to use an external response policy provider.  This allows the same 
type of policy filtering as standard RPZ, but can reduce the workload 
for named, particularly when using large and frequently updated policy 
zones.  It also enables named to share response policy providers with 
other DNS implementations such as Unbound.  Thanks to Vernon Schryver 
and Farsight Security for the contribution."


Link - BIND 9.12 development is getting closer to completion!
 - https://www.isc.org/blogs/bind-9-12-almost-ready/

I have long considered RPS for DNS to be like the milter API for email.



--
Grant. . . .
unix || die

--
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.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ISC, GitHub, and CVE-2025-30066

[Ondřej Surý]

> On 20. 3. 2025, at 23:12, John Thurston  wrote:
> 
> And since I know that ISC has projects at GitHub, and I suspect that ISC 
> projects would be a big, fat, juicy target for code injection, I feel like I 
> gotta ask . . Is ISC willing to weigh in and say if their projects may have 
> been affected, or if credentials for their projects may have been exposed?

We don't use GitHub as primary platform and we push only public branches to 
GitHub as read-only mirrors.

I do run some extra checks on GitHub (like CodeQL and SonarCloud because of the 
integrations), but this was the first time I've ever heard about tj-actions in 
my life.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.




signature.asc
Description: Message signed with OpenPGP
-- 
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.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Custom DNS Filtering Plugin in BIND 9

[Michael De Roover]

On Wednesday, March 19, 2025 4:05:29 PM CET you wrote:
> Michael,
> 
> you can hardly create a static list from all of the domains that can
> possibly exists.
> 
> I do understand the usefulness of dynamic classification.
> 
> There’s just not a straightforward interface for it now. Somebody will have
> to invest into writing this :shrug:
> 
> Ondrej

Hi Ondrej, I commend your productivity! I saw your work in both BIND-Users and 
DNSOP. 
No joke, we need more people like this, especially right now. Having had a 
productivity 
boost on the same day, fist-bump!

To be fair though, not all domains have to be recorded into an RPZ to be 
useful. For me 
right now, it's only a couple of domains related to Facebook, YouTube, Windows 
Update, 
and Tor. Wildcards being allowed, means that this zone is only 42 lines long.

> Thinking aloud - perhaps, we can extend the plugin API (and RPZ) in a way to 
> add the 
classification to the message processing and then the RPZ processing could read 
the 
classification and take an action?

> But that’s quite a huge chunk of work.

About that... I like the idea, but can you guarantee that it stays within BIND? 
How would 
you envision such traffic flow from threat analysis to zone inclusion? Would 
such additions 
to the protocol require standardization in DNSOP?

The way I envision it is as follows:

Suppose that a request is made to malicious01.nixmagic.com. Sentinel node on 
ns1.internal.nixmagic.com makes a report, and wraps it up into an intervention 
package. 
This is to be pushed into the RPZ zone, or whatever else is responsible for DNS 
rewrite 
through internal DNS - BIND here.

So that sentinel program made its call, classified it locally, and pushed new 
records 
accordingly. Does the DNS server and its zone file still need to know more than 
that? If so, 
how does that affect the protocol performed between sentinel and nameserver, as 
well as 
the protocol performed between nameserver and future clients? If not, could it 
redirect to 
different destinations based on such classification data?

My concern here is mostly with the protocol, and where these databases are 
held. My 
belief is that the DNS server does not need to know about the classification 
details of such 
a threat. That's the responsibility of the sentinel to determine, and keep 
records of.

That being said, I do like the idea of exploring this into further detail. As 
you may be able 
to tell by now, I have explored the idea of a sentinel as an SMTP edge before. 
Provided 
sufficient actionable rationale and/or code relevant to BIND, would ISC be 
willing to 
collaborate on such an ordeal?

> If this is something that is going to be open-source and the whole BIND 9 
> users 
community would benefit from this, I would love to hear and see more.

Out of curiosity, do you think that the code I wrote for building zone files 
may be useful 
here? I committed it locally as mkbind, similar in nature to keama. However, 
the JSON 
syntax is built only against my own infrastructure, which is not as complex as 
that of 
other members on this and the DNSOP list. Most importantly, it still deals with 
/24 only. 
Binary conversion to handle classless.. it's a roadmap item, but one I'd rather 
push down 
until needed. Nonetheless, it can handle zones and has several logic items for 
deduplication (e.g. A/PTR, mobility between zone suffixes, etc).

-- 
Met vriendelijke groet,
Michael De Roover

Mail: i...@nixmagic.com
Web: michael.de.roover.eu.org
-- 
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.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ISC, GitHub, and CVE-2025-30066

[John Thurston]

I was reading about CVE-2025-30066. I must admit that my git-knowledge 
is close to nil, but if I'm reading the description right then this CVE 
is describing a pathway which let bad-actors potentially gain keys to 
other projects in GitHub.


Projects that used the compromised version of 
*tj-actions/changed-files* between March 12, 2025, 00:00 and March 15, 
2025, 12:00 UTC are at high risk. In these cases, sensitive 
credentials may have been exposed via public logs. [From sysdig.com 
]


And since I know that ISC has projects at GitHub, and I suspect that ISC 
projects would be a big, fat, juicy target for code injection, I feel 
like I gotta ask . . Is ISC willing to weigh in and say if their 
projects may have been affected, or if credentials for their projects 
may have been exposed?



--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
-- 
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.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Custom DNS Filtering Plugin in BIND 9

[Marcus Kool]

I wrote a closed source filtering plugin for BIND and I found that the #1 issue 
is that there is no defined interface between a plugin and BIND internal data 
structures.
Since data structures (may) have small changes between patch releases, this implies that with /every/ release of BIND, the plugin /must/ be recompiled and a new release of the plugin must be made to 
ensure that the plugin works correctly when accessing or manipulating the data structures.
There is no issue when a plugin is part of BIND, e.g. the filter- plugin, but for any other (open source or not) plugin one must recompile the plugin for every patch release and make sure that the 
plugin version and bind version match exactly.

It would be nice for all authors of plugins that this issue is 
resolved/improved.

Marcus


On 20/03/2025 13:58, Michael De Roover wrote:


On Wednesday, March 19, 2025 4:05:29 PM CET you wrote:

> Michael,

>

> you can hardly create a static list from all of the domains that can

> possibly exists.

>

> I do understand the usefulness of dynamic classification.

>

> There’s just not a straightforward interface for it now. Somebody will have

> to invest into writing this :shrug:

>

> Ondrej


Hi Ondrej, I commend your productivity! I saw your work in both BIND-Users and DNSOP. No joke, we need more people like this, especially right now. Having had a productivity boost on the same day, 
fist-bump!



To be fair though, not all domains have to be recorded into an RPZ to be useful. For me right now, it's only a couple of domains related to Facebook, YouTube, Windows Update, and Tor. Wildcards 
being allowed, means that this zone is only 42 lines long.



> Thinking aloud - perhaps, we can extend the plugin API (and RPZ) in a way to 
add the classification to the message processing and then the RPZ processing could 
read the classification and take an action?

> But that’s quite a huge chunk of work.


About that... I like the idea, but can you guarantee that it stays within BIND? How would you envision such traffic flow from threat analysis to zone inclusion? Would such additions to the protocol 
require standardization in DNSOP?



The way I envision it is as follows:


Suppose that a request is made to malicious01.nixmagic.com. Sentinel node on ns1.internal.nixmagic.com makes a report, and wraps it up into an intervention package. This is to be pushed into the RPZ 
zone, or whatever else is responsible for DNS rewrite through internal DNS - BIND here.



So that sentinel program made its call, classified it locally, and pushed new records accordingly. Does the DNS server and its zone file still need to know more than that? If so, how does that 
affect the protocol performed between sentinel and nameserver, as well as the protocol performed between nameserver and future clients? If not, could it redirect to different destinations based on 
such classification data?



My concern here is mostly with the protocol, and where these databases are held. My belief is that the DNS server does not need to know about the classification details of such a threat. That's the 
responsibility of the sentinel to determine, and keep records of.



That being said, I do like the idea of exploring this into further detail. As you may be able to tell by now, I have explored the idea of a sentinel as an SMTP edge before. Provided sufficient 
actionable rationale and/or code relevant to BIND, would ISC be willing to collaborate on such an ordeal?



> If this is something that is going to be open-source and the whole BIND 9 
users community would benefit from this, I would love to hear and see more.


Out of curiosity, do you think that the code I wrote for building zone files may be useful here? I committed it locally as mkbind, similar in nature to keama. However, the JSON syntax is built only 
against my own infrastructure, which is not as complex as that of other members on this and the DNSOP list. Most importantly, it still deals with /24 only. Binary conversion to handle classless.. 
it's a roadmap item, but one I'd rather push down until needed. Nonetheless, it can handle zones and has several logic items for deduplication (e.g. A/PTR, mobility between zone suffixes, etc).



--

Met vriendelijke groet,

Michael De Roover


Mail: i...@nixmagic.com

Web: michael.de.roover.eu.org

-- 
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.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users