[ISC BIND 9.10.2-P1 and older] "flawed" zone file modification check
Hi bind-users,
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.
First I will list steps to reproduce, and then I will explain how I
encountered this scenario and how it may occur for another user, finally
ending with a workaround and suggested fix.
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.
Understandably, the former issue is not exactly BIND's fault; in fact
neither of them are. It's also trivial to work around this scenario:
simply restart BIND and it will no longer have impaired judgement of
time as it will load with the correct system time from the very start.
That being said, this edge case is also trivial to avoid. Instead of
storing the time when each zone was loaded as per line 1794 of dns/zone.c:
/*
* Store the current time before the zone is loaded, so that if the
* file changes between the time of the load and the time that
* zone->loadtime is set, then the file will still be reloaded
* the next time dns_zone_load is called.
*/
TIME_NOW(&loadtime);
/*
* Don't do the load if the file that stores the zone is older
* than the last time the zone was loaded. If the zone has not
* been loaded yet, zone->loadtime will be the epoch.
*/
if (zone->masterfile != NULL) {
...
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'.
Thoughts?
--
Milos Ivanovic
___
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
Re: [ISC BIND 9.10.2-P1 and older] "flawed" zone file modification check
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
Re: [ISC BIND 9.10.2-P1 and older] "flawed" zone file modification check
In article , Milos Ivanovic 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 ___ 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
Re: [ISC BIND 9.10.2-P1 and older] "flawed" zone file modification check
In message , Barry Marg olin writes: > > 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. If you recover from backup you will also generally want to bump the serial to that which is more than the slaves or else your slave won't pick up the "current" contents. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
