Investigate and update the documentation on mirror zone update and validation process when using IXFR
The documentation on the operation of mirror zones says:
A mirror zone acts like a zone of type secondary whose data is subject to DNSSEC validation before being used in answers. Validation is performed during the zone transfer process (for both AXFR and IXFR), and again when the zone file is loaded from disk when named is restarted. If validation of a new version of a mirror zone fails, a retransfer is scheduled and the most recent correctly validated version of that zone is used until it expires; if a newer version of that zone is later correctly validated, it replaces the previously used version. If no usable zone data is available for a mirror zone (either because it was never loaded from disk and has not yet been transferred from a primary server or because its most recent correctly validated version expired), traditional DNS recursion will be used to look up the answers instead.
Mirror zone validation always happens for the entire zone contents, i.e. no "incremental validation" takes place, even for IXFRs. This is required to ensure that each version of the zone used by the resolver is fully self-consistent with respect to DNSSEC. Other, more efficient zone verification methods may be added in the future.
Note also that we're aware that the task that is handling the validation will never yield - this was intentional (validating the root zone should not take too long) as mentioned in issue #774 (closed)
However, our suspicion is that an inbound update to a mirrored root zone that is performed as IXFR could be particularly poor on performance due to way each increment is applied.
Please could the behaviour of named when processing an inbound IXFR to a mirrored root zone be investigated, and, if necessary, optimised so as not to impede the functionality of a resolver's ability to simultaneously handle client queries with DNSSEC validation enabled.