New logging category to warn about partially-applied zone updates
The problem is that we don't have a suitable RCODE for handling 'this update was refused or incompletely applied because it breaks policy'.
This is a quite distinct scenario from the usual one that is routinely logged - that a client update request was received but refused because the client was not permitted to update either the zone, or these records, per the configured ACLs or update-policy.
In this scenario, the client IS permitted to update the zone and these RRsets, but the update cannot be completed because either it breaks DNS protocol (for example CNAME cannot coexist with other RRs at the same name), or, per the new policy created in #1657 (closed), it's permitted for the client to add these RRs, but there's a limit on how many are permitted to exist in the zone per name/type, in which case the update will 'succeed', but some of the new RRs will silently fail to be added to the RRset.
Since the client expects to be allowed to update the zone, and hasn't received any error code in response to the update request, they will not know that the update wasn't completed 'successfully'.
It would be a pretty decent thing to do, to at least log this, so that looking back, an explanation is possible for why he zone doesn't contain quite what was expected.
- It is reasonable to expect that an administrator of a zone, having permitted dynamic updates, AND set some policies about the zone structure, does properly 'manage' their tools so that hitting policy limits is an exception or an accident.
- It is also reasonable to expect that a zone administrator, should something not go quite according to plan, will want to look in the logs for evidence of what did or didn't happen.
- We should give administrators the ability to log (or not log) this type of situation separately from the other security policy based update failures - hence the the request for a separate logging category.