On Sun, Feb 07, 2021 at 06:27:24PM +0100, Christopher Zimmermann wrote: > On Sun, Feb 07, 2021 at 04:20:26PM +0000, Stuart Henderson wrote: > > On 2021/02/07 17:04, Christopher Zimmermann wrote: > > > Hi, > > > > > > a year ago I added support for our pf tables to the unbound ipset module. > > > Upstream does not seem eager to merge it: > > > https://github.com/NLnetLabs/unbound/pull/144 > > > > > > Implementing pf tables support was pretty straightforward. It has been > > > more > > > work to adjust module's privilege management to allow the modules to open > > > privileget files like /dev/pf and keep them open across reloads. > > > This is also what upstream was unsure about. > > > > > > So below you find the diff against our base unbound. > > > > > > Should this go in? Continue to wait for upstream? > > > Suggestions for improvement? > > > > I would not be happy about including this in base unbound. Partly > > because it is a large diff to carry, partly unbound is a much more > > complex process than I'd be happy with having direct access to > > reconfigure PF. > > > > The whole approach (including for linux ipset) doesn't seem ideal to > > me. It would seem much better to have this done out-of-process with a > > communication mechanism to allow sending the addresses across, then > > unbound wouldn't need firewall-specific knowledge in the code, and > > there's a clear separation of privilege. > > Hi Stuart and Florian, > > thanks for giving a thought. I agree to your analysis. > It seems to me a more sane approach would be to change / create an "ipset" > module that doesn't talk a specific ipset / pf protocol, but simply dumps > raw ipv4 /ipv6 addresses in a file / fifo / pipe, which can then be consumed > by a thin privileged translator process that adds those ips to pf / ipset / > whatever. This would also get rid of the privilege management issues I > encountered.
having unbound fiddle with pf tables itself also means that you'd have to run unbound on the firewall actually moving the packets around. this is fine in a small environment, but as soon as you add a redundant firewall you will need to sync tables between the firewalls and then unbound gets even more complicated. then you'll want to run the resolvers on separate boxes to the firewalls and then it gets even more complicated again. unbound has support for dnstap (https://dnstap.info/), which basically sends a copy of the dns messages it handles along with some metadata to a listener. a dnstap receiver that wants to do something interesting with those messages has to be able to parse dns packets. an example of something interesting might be mapping domain names to ips and distributing them to firewalls would be https://github.com/blind-oracle/dnstap-bgp. however, dnstap is not enabled in base unbound because it has some dependencies we don't want in base. im working on a simpler message encapsulation and transport that is dumb enough to not need extra depends in base, but it is barely more than a prototype at this stage. > Now I'm just wondering whether the filtering feature of ipset should remain > in unbound or be moved to another process. I would tend to keep it within > unbound, since parsing queries is what it is built to do after all. if you follow the dnstap example, the other process does the filtering and downstream stuff. i think it would be Good Enough(tm). dlg
