Per-local zone ipset declarations with TTLs

[Kilrain, Jack]

Hi all,

It’s been a few months and I just want to check in on this and see if anyone has thought about the proposed changes for per-local zone ipsets.

I also noticed that there are some changes in PR for nftables support by buevsan: https://github.com/NLnetLabs/unbound/pull/1196. Which makes me wonder about support between the two. I.e. refactoring my changes post-merge of nftables support to ensure compatibility. Otherwise in the inverse case of merging these changes and refactoring the nftables work to conform.

Cheers,
Jack

From: Kilrain, Jack <Jack.Kilrain at netapp.com>
Date: Thursday, 14 November 2024 at 5:33 pm
To: Unbound Mailing List <unbound-users at lists.nlnetlabs.nl>
Cc: Raevski, Gregory <Gregory.Raevski at netapp.com>
Subject: Per-local zone ipset declarations with TTLs
Hi all,

I recently raised a PR to add support for per-local-zone ipset specification, allowing for more than one ipset to be used and set TTLs on the ipset entries based on RRSet timeout field values which can be conditionally enabled (implementation details, config examples and reasoning can be found on the PR): https://github.com/NLnetLabs/unbound/pull/1162

I wanted to discuss a few things here:

  1.  Asking for reviews and opinions on it, plus any assistance I can give to get it into a state that is mergable
  2.  Necessary changes for the Debian package to add the CAP_NET_ADMIN support conditionally on compilation with --enable-ipset (possibly detect this based on env vars set from the configure script) to update the apparmor profile with the capability
  3.  BSD’s packet filter framework has no support for per-entry TTLs into a table, i.e. can only evict entries from a table based on a delta invoked on the table itself, implying no automatic eviction. If someone more familiar with BSD than I has any idea on this, would be great to hear about a potential solution.

In terms of use case, we are looking to use Unbound as a forwarding DNS server which conditionally adds resolved addresses into ipsets for firewall passthru. Essentially a DNS firewall. Given we have services that talk over various ports and protocols, the restriction of a single global ipset makes it impossible to distinguish entries on a per-port/protocol/etc basis from a single ipset.

Would be great to hear some feedback, opinions etc on this. Open to anything.

Cheers,
Jack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20241219/58be5b79/attachment.htm>