GitLab

From Support Ticket #16268

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.