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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
