William_D. Colburn <[email protected]> wrote: > > What I want to know now: is there a better solution to that problem than > what I did? Better practices for fixing that which I could have followed?
I think recovering from a secondary copy is about the best you can do. The zone file and journal are no longer consistent with each other, but the tools expect and require them to be consistent. There's an exception: named-journalprint looks at the journal only, not the zone file, so it doesn't require them to be consistent. So you can recover by using named-journalprint to get a human-readable list of changes to the zone, manually apply them to the zone file, then delete the journal and restart `named`. This is much more tedious and error-prone than a zone transfer, but it's an option to keep in mind in case you get into more serious trouble. To avoid the problem in the future, you can make this mistake less likely by changing the masterfile-format to "raw", so that if anyone tries to load the file into an editor they will be confronted by gibberish, and hopefully (!) look for documentation that explains the right way to modify the zone. My primary server has raw dynamic zones, and I use `nsvi` to edit dynamic zones in place, or `nspatch` to update a live zone from a file stored in version control. https://dotat.at/prog/nsdiff/ -- Tony Finch <[email protected]> (he/they) Cambridge, England Southeast Iceland: Southwesterly severe gale 9 to violent storm 11, becoming cyclonic 6 to gale 8 later. High or very high, becoming mainly very rough later. Rain. Moderate or poor. -- 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 [email protected] https://lists.isc.org/mailman/listinfo/bind-users
