Bug #45694 for bind9-public: Spurious "zone may fail to transfer" log entries

bind 9.11.1-P2.

named seems to be too aggressive in producing "zone serial unchanged. zone may fail to transfer to slaves" messages.

A burst of these messages got me to do some investigation.

This adventure started with:

    rndc freeze; sleep 5; rndc thaw

This resulted in syslog messages of the form:

    zone 135.168.192.IN-ADDR.ARPA/IN/internal: zone serial (2017072000) unchanged. zone may fail to transfer to slaves.

from a subset of dynamic zones.  It is true that the serial didn't change.  But neither did the zone contents.

Repeating the freeze/thaw command does not produce additional messages.

Next, I added a (TXT) record to a zone with UPDATE.  Repeat freeze/thaw; no message.
However, after waiting about a minute and repeating the grep: that message appeared for the zone.

Deleting the record follows the same pattern; freeze/thaw + delay results in 'zone may fail to transfer'.

Looking into the code, the message comes from lib/dns/zone.c: zone_postload().

zone_load() attempts to prevent loading if the master file has not been modified (!zone_touched()).

zone_touched() uses zone->loadtime/include->filetime and the master file's mtime to determine whether the zone data file has been modified since load.

I didn't track this back further, but from the symptoms I suspect that applying the journal is not updating zone->loadtime/include->filetime.  Thus, zone_load() would conclude that the file has been modified, and after the load, zone_postload notes that the serial hasn't changed.

If I'm correct, applying the journal & writing a new zone data file should set those fields in the zone structure to the data file's new mtime().  Although the data file's mtime and contents change, the pre-freeze file + journal has the same contents as the post-freeze file.  Both match the zone data in memory.  So updating the zone structure's idea of load time would correctly reflect the state.

Nit: In the message, "zone may fail ..." should be "Zone may fail". (Though perhaps fixing that would confuse log file scanners.)

-- 
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

---