Re: Proposed Improvements to NPF

[Martin Husemann <martin%duskware.de@localhost>]

On Sun, Jun 08, 2025 at 06:05:00AM -0400, Greg Troxel wrote:
> Martin Husemann <martin%duskware.de@localhost> writes:
> 
> > On Sat, Jun 07, 2025 at 08:52:56PM +0000, Josh Moyer wrote:
> >> As for "DNS lookups", I was thinking of using gethostbyname(3), Olaf, so I'm
> >> sure that nsswitch.conf would be honored.  Greg's use case reasonably
> >> matched my own, so I think we're all on the same page here.
> >
> > Supporting those sounds fine (and it is admins repsonsibility to avoid
> > the deadlocks mentioned, i.e. not rely on an external DNS that is
> > blocked during initial load of the NPF configuration, e.g. by using
> > /etc/hosts entries for the relevant parts).
> 
> This doesn't solve the problem the feature is intended for.  I think we
> need reasonable fallback behavior, not UB if the admin doesn't organize
> things impossibly.

We certainly need to define what happens to a rule that uses a host name
if host name lookup fails. It should not be undefined behaviour.

Obvious choices are: (1) drop the rule [this is my favorite] loudly,
(2) provide syntax for fallback addresses (hard to get right for
the admin, but easy to implement), (3) fail the whole config
loading (IMHO worst option).

> > However, I wouldn't go as far as make host names fully dynamic, that
> > is: for hosts that might change their IPs during livetime of the NPF
> > configuration, do not even try to make NPF deal with this itself.
> 
> That is all hosts.  There is no bound on a configuration being loaded,
> and IP addresses can change at any time.  There are hosts that are very
> unlikely to change, and those that are more likely, of course.

Yes, and you probably know about them when they appear in your NPF config.
Worst you can rely on DNS TTL values.

All of this (IMHO) should be NOT part of NPF, but local admin choice
and something else. We have plenty of tooling for similar cases with
dynamic clients already, including resolvconf and ifwatchd, maybe we need
to create other tools for DNS TTLs - or just rely on cron.

> > Instead use other mechanisms to force a reload of the (same/static) NPF
> > configuration at the proper times.
> 
> I think it should be dynamic, on some time scale, but that's NPF the
> system, not NPF the kernel.  Which amounts to the same thing as what you
> are saying, I think.

There is no NPF deamon running that could deal with this and I would strongly
suggest NOT to introduce one just for this corner cases.

Martin