hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[Tony Finch]

Matthijs Mekking <matthijs at isc.org> wrote:
>
> A brief summary. Folks that are interested in the reasons why can read
> up and discuss here:
>
>    https://gitlab.isc.org/isc-projects/bind9/-/issues/1890#note_220217

So the fundamental design issue here is related to edge-triggered vs.
level-triggered activities, and which is easier to implement both for
named and for the hostmaster's scripts.


With an edge-triggered design you have to avoid falling into the trap of
assuming that exactly-once is possible (it isn't!) so you need a closed
feedback loop with retries. Specifically, for key management, named needs
to be able to say, I have changed the state of this key, and keep saying
that at every key refresh interval until some script confirms that it has
done what it needs to do, before named moves on to the next state. (This
applies to changes like newly created keys that need to be saved, as well
as CDS state changes.)

How should named say that a key has changed? It's a multithreaded program
so it can't fork (not without a single-threaded helper process) so maybe
it should fire off a message to a socket that the script machinery can
listen to. (Maybe abuse NOTIFY for the purpose?) The feedback loop can be
closed using an rndc command.


The questions for a level-triggered design are more to do with
introspection and performance. Introspection: how can I find out the state
of the keys and the state of the world, detect if there is a mismatch,
and know what needs to be done to get the world to match the keys?
Performance: do I have to do this check every hour (or whatever the key
maintenance interval is) for every zone, or is there some way to avoid
futile repeated work?

In a level-triggered design it must still be possible to configure named
not to move on to the next state without confirmation from the script that
it is safe to do so, e.g. using rndc, same as is needed in an
edge-triggered design.


In my case I'm storing keys in a git repository, encrypting the private
parts with gpg, so I need to know about all key state changes, not just
CDS changes. I can implement a level-triggered design using something like
`git status` and/or `git diff` to detect mismatches (assuming my script
only commits to the git repository when it is sure it has updated the
world as required). That will perform OK at my small scale, but I'm not
sure if I have the necessary introspection tools - I guess I'll have to
grovel around in the guts of the key files to find out what needs doing?

An edge-triggered design would be a bit easier since my script would just
receive an instruction and act on it in an idempotent manner. No need for
it to woek out what has changed or what needs doing, and it would clearly
scale per change rather than per zone.


Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: South
or southwest 4 or 5, occasionally 6 near Anglesey, becoming variable 2
to 4 later. Slight, occasionally moderate. Fair at first, then
occasional rain or drizzle. Moderate or good, occasionally poor.