named-checkzone should check jnl to avoid a zone not loading due to: journal out of sync with zone (and other related issues)
Description
- If a non-dynamic but journaled zone is modified when named is stopped, named cannot load the zone on startup. (This could be considered a bug, but is being filed as a feature request.) Likewise, the same situation can occur with named running, if the journal isn't properly updated during a zone reload (That scenario can be forced by removing write access to the journal file).
- When ixfr-from-differences is set, the -j option for named-checkzone incorrectly reports sync problems. Perhaps I'm getting too far out over my skis, but I think that -j in the presence of ixfr-from-differences is never useful and commonly wrong.
Request 1
- Ideal request: named-checkzone should discover problem number 1 and give a warning.
- This is not just requesting that named-checkzone default to use the '-j' option.
- There will be problems trying to implement this. It requires named-checkzone to know that "ixfr-from-differences true;" has been set, which would require reading named-checkconf. (We don't want a warning if ixfr-from-differences not set.) Additionally, named-checkzone would also need to read named-checkconf to find the journal file. Yes, it could assume that the journal is in the same directory as the zone file, and has the default file name, however, that doesn't cover all cases.
- More realistic request: named-checkconf -z should discover the problem without requiring the -j option.
Request 2 (Perhaps this is a bug)
When ixfr-from-differences is set, the -j option incorrectly reports journal rollforward problems, and claims that the zone will not load, when everything is in fact fine and rndc reload works perfectly well.
The scenario is simple common use:
- The zone file is modified manually. The SOA serial is increased.
- named-checkzone reports no errors.
- named-checkzone -j incorrectly reports: "jounal rollforward"
- rndc reload works perfectly.
- named-checkzone -j reports no errors.
Question
Are there similar documented cases of "named-checkzone " reporting a zone OK, but named not being able to load it? If the answer is no, than this seems like a bigger deal to me. Perhaps incorrectly, but it is widely accepted that when named-checkzone reports no errors, it is safe to reload the zone. If there are already several cases where that is not true, than this is just one more. However, if this case is unique, the trust in named-checkzone has a crack in its foundation.