Re: Proposed Improvements to NPF

[Greg Troxel <gdt%lexort.com@localhost>]

Josh Moyer <JMoyer%nodomain.net@localhost> writes:

I should have said that I think it's fine to have the big-picture
discussion of various things in parallel.  That is less human time but
more elapsed time than doing the work.


> 3: DNS hostname lookup support.  (Is this a bad idea from a remote
> firewall rule manipulation attack type of perspective?)

(I agree with Edgar's chicken/egg comment.)

I suspect many won't like this, and thus will accept as obvious that it
has to be entirely optional, so that those who don't try to use the
feature won't see it.

There is a security argument, but I don't think that should stop the
feature, because different people have different needs. 

As a use case, I can see a host allowing some ports from a list of known
peers, some of which might use dynamic dns.

That leads to wanting:

  - some way to define a variable as the result of dns lookup, perhaps
    looking like ifaddrs

  - the idea that if dns lookups fail the set is just empty, so that you
    can start up without dns and still load most of the rules, failing
    safer, assuming dns is used to allow

  - later, if lookups work the new values are swapped in

  - dns is requeried periodically and changed values are swapped in

and that's going to perhaps need a background reload via npfctl as
surely we aren't going to have the kernel doing dns lookups, and that
might lead to a daemon.  Perhaps the dns table will be like a blocklist
and be modifiable without a reload, like dynamic rules.  That's all
fuzzy, but things to look into as you think about how to do this.