Update mirror zones documentation - this type of zone is unsuitable for large/complex TLDs (performance does not scale)
From Support ticket #13765
Mirror zones are optimised/simplified for handling the root zone effectively and efficiently
Our documentation failed to emphasize that using the mirror zone feature for anything else than the root zone should currently be considered "experimental" - as in, "feel free to do it, please report the issues you are seeing, but we only expect it to work in a stable manner for the root zone - the outcome may be very different in other circumstances".
For mirror zones, after initial loading or updating there is now the zone validation step too. This takes place:
- When the zone has just been loaded from disk
- When the zone has been updated by AXFR
- When the zone has been updated by IXFR
The validation step is a full DNSSEC validation of the entire zone content, (from ZSK to trust anchor (KSK)) - we don't just check incremental changes.
The reason for this is that a full validation of the zone being mirrored is what was specified as the requirement to ensure its authenticity, and at the moment there is not another mechanism available for verifying the zone.
The validation takes place synchronously in a task running on one of the worker threads. The task will not yield until it has completed (in other words, this is not a task that will pause, let another task do some processing, and then resume again for another iteration.
We did this deliberately:
a) This feature was designed for the root zone, for which this is essentially a non-issue (due to its size). We have a CPU-greedy task, and one that we want to complete quickly so that the zone can be used.
b) It was understood that having a non-yielding validation task should only be an issue for single-threaded named instances,
c) Doing validation asynchronously would inflate the complexity of implementing the whole feature, but even worse: it could cause issues even for configurations not using mirror zones (because the post-zone-load code affects all types of zone).
The future may bring some faster ways of validating whole zones (see https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/) - but we're not there yet.
So for now, we need to make it clearer to potential users of mirror zones for other than the root zone, that this may not be in their best interests.
(And in any case, serve-stale, prefetch, and well-distributed and well-provisioned authoritative servers will suffice for most use-cases).