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.Also
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.