[ISC BIND 9.10.2-P1 and older] "flawed" zone file modification check

[Rob Foehl]

On Tue, 30 Jun 2015, Milos Ivanovic wrote:

> I've encountered an edge case that was not considered while developing
> the method that BIND uses to check if a zone file has been modified. I
> will immediately state that this is an extreme edge case, but
> nonetheless one that should (and can) be avoided with minimal change to
> the source code.

I reported a similar issue with zone reloads being lost during initial 
startup on servers with large numbers of zones (100k+) on bind-workers a 
while back:

https://lists.isc.org/pipermail/bind-workers/2015-March/003313.html

and also reported as ISC-Bugs #39424 a couple months ago.  I suspect it's 
the same underlying issue, although I haven't found time to look into this 
in detail.

> it would be wiser to store the mtime of each zone file instead, and
> simply compare the stored mtime with the current mtime when a reload is
> requested, alleviating the need to rely on the system time at all. This
> gives more certainty that a reload will be granted if a file is touched,
> even if that file was modified "in the past" in terms of BIND's start time.
>
> Of course, the best way to verify zone changes is to actually check the
> serials, but I understand the current implementation is the way it is
> for performance reasons - namely, to avoid parsing all zone files when a
> `rndc reload' is issued by older versions or those who do not realise
> that this command can be avoided when editing single zones in favour of
> the newer `rndc reload yourzone.example.com'.

Agreed on all counts -- I have a feeling the mtime discrepancies are at 
the root of the issue I'd run into.  Thanks for the pointer!

-Rob