[knot-dns-users] Impossible to purge zone data for unconfigured zone

Hello Knot DNS developers, I have an observation about newer versions of Knot which use the new single LMDB-based journal. Suppose I have 3 slave zones configured in my knot.conf. Let's call them zone1, zone2 and zone3. Knot loads the zones from the master and writes data into the journal. Now suppose I remove one zone (zone3) from the config, and reload knot. The zone is no longer configured, and querying knot for it returns a REFUSED response. So far all is according to my expectation. However, if I run "kjournalprint <path-to-journal> -z", I get: zone1. zone2. zone3. So the zone is no longer configured, but its data persists in the journal. If I run "knotc -f zone-purge zone3." I get: error: [zone3.] (no such zone found) I'm told that I should have done the purge first, *before* remove the zone from the configuration. However, I find this problematic for 2 reasons: 1. I have to remember to do this, and I'm not used to this modus operandi; and 2. this is impossible to do on a slave that is configured automatically from template files. On our slave servers, where we have around 5000 zones, the zones are configured by templating out a knot.conf. Adding zones is fine, but if a zone is being deleted, it will just disappear from knot.conf. We keep no state, and so I don't know which zone is being removed, and cannot purge it before-hand. Now, the same is kind of true for Knot < 2.4. But... there is one major difference. Under older versions of Knot, zone data was written into individual files, and journals were written into individual .db files. I can run a job periodically that compares zones in knot.conf with files on disk, and delete those files that have no matching zones in the config. This keeps the /var/lib/knot directory clean. But in newer versions of Knot, there is no way to purge the journal of zone data once a zone is removed from the configuration. For an operator like me, this is a problem. I would like "knotc zone-purge" to be able to operate on zones that are no longer configured, and remove stale data anyway.