"not exact" error message

[Mark Andrews]

> On 22 Jan 2023, at 09:54, Havard Eidnes <he at uninett.no> wrote:
> 
>> The consistency checks are not new. The message indicates that
>> the IXFR contained a delete request for a record that doesn't
>> exist or an add for a record that exists. Named recovers be
>> performing an AXFR of the zone.
> 
> Interesting.
> 
> BIND 9.16.36 does not produce this log message, so it was easy to
> be misled to conclude that this was a new consistency check.
> Does 9.16.36 and 9.18.10 behave differently in terms of their
> usage of IXFR?
> 
> The log message BIND 9.18.10 produces does not mention IXFR or
> that it's going to fallback to AXFR.  I mis-interpreted it as a
> fatal error message, and downgraded to BIND 9.16.36 without
> verifying whether 9.18.10 actually worked as intended anyway (it
> does, I just re-instaled 9.18.10 and re-signed a zone and
> verified that it makes it through).

The log message can only be produced when an IXFR stream is being
processed.  The consistency checks have been there as long as IXFR
has existed.  There are too many ways that zone content can be
changed by administrators incorrectly.  Then there are other behaviours
that lead to inconsistencies.  Transferring from multiple Microsoft
Windows Active Directory servers can produce this, the LDAP synchronisation
doesn’t ensure that a given serial number matches the same content on each
server.  Transferring from multiple servers each doing their own
inline-signing can produce this (RRSIGs will differ between servers
as the RRsets are changed at different times and zone serial numbers
may also differ).

There are a whole heap of reasons for IXFR to fail, this being one
of them, and named will fall back to AXFR on any of them.

> Regards,
> 
> - Håvard

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org