GitLab

Tying loosely into Support ticket #16268

We were never able to replicate problems with client resolution during mirror zone refresh (using IXFR), and neither were we able to replicated 'slowness' of updating the zone itself. The suspicion is now that the reported issues were due to something else and what we were seeing was symptom not cause.

However, along the way (and in #1802 (closed) and #1803 (closed)) what was re-exposed is that the validation step for mirror zone updates doesn't take place within an iterator, so it's anti-social, in that it doesn't relinquish the CPU/thread it's working on until it's finished. This is documented as a known feature of the mirror zone implementation, and most of the time it really should not matter (it doesn't take long to validate the entire root zone, which is what the mirror zone implementation was designed for).

This issue ticket is a placeholder to note that we considered this something that we'd like to do, although it's not burningly urgent in the bigger picture of Things That Need To Be Done.

(We also uncovered that the validation step takes place against the entire zone, for each increment being applied (increment = bundled set of changes between SOA start and end RRs, not each individual change), so is potentially inefficient when pulling IXFRs rather than AXFRs from the root servers - but this has to be balanced against the rate of flux of the mirror zone (low for the root zone), so it's probably not worth tackling this too. )