Re: Proposed Improvements to NPF
Greg Troxel <[email protected]> Sun, 08 Jun 2025 06:05:00 -0400
| Newsgroups | gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <[email protected]> |
Martin Husemann <[email protected]> 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. > 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. > 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.