Re: Proposed Improvements to NPF

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

Martin Husemann <martin%duskware.de@localhost> writes:

>> 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).

I think of those, only option 1 is reasonable, with a warning.  I guess
right now we might not have warnings, just silent success and errors.

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

TTL is unrelated to odds of dynamic DNS, in my experience.

> 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.
>
> 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.

This needs a design, considering the options, and rationale.  Certainly
"instruct the admin to configure cron to reload periodically" is an
option.