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

[Barry Margolin]

In article <mailman.2211.1435607399.26362.bind-users at lists.isc.org>,
 Milos Ivanovic <bugs at milos.nz> wrote:

> To reproduce:
> 1. Set the hardware clock to some time in the future
> 2. Boot the system, including BIND
> 3. Let NTP fix the time, or fix the time manually
> 4. Edit a zone, finishing by increasing its serial
> 5. run `rndc reload yourzone.example.com'
> 6. receive `zone reload up-to-date',
>    or if you have debugging enabled `skipping load: master file older
>    than last load' will appear in the logs
> 
> As you can see, BIND does not account for clock drift. This will be an
> issue for users that have specific (bogus) /etc/adjtime file offsets or
> are changing timezones such that it would ultimately result in moving
> the system time backwards after having started BIND.

Lots of things on Unix depend on the clock not going backwards. This is 
why adjtime normally works by simply slowing down the clock to let the 
real time catch up, rather than set the clock back. It only sets the 
clock back in extreme cases, when the clock is so far ahead that it will 
take too long to get in sync. If this happens to your system frequently, 
you have bad hardware, and it's hardly up to BIND to try to deal with it.

However, I agree with your suggestion.

> 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.

Furthermore, it's not necessarily true that you want to ignore a zone 
file just because it's older than the one previously used. Suppose you 
restore a zone file from a backup, and it gets the original mtime. 
Wouldn't you want a reload to pick this up? Maybe it should warn about 
it, but not reject it completely.

-- 
Barry Margolin
Arlington, MA