Matthijs Mekking <matth...@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 <d...@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. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users