On 2013-07-02 at 17:15 -0400, Doug Calvert wrote: > It is worth pointing out that parsing the file may be a better route. > If the system clock is whacky and unbound updates the last queried > time in root.key the ctime on the file will also be whacky. Parsing > the root.key file might be the best option:
The time put into the file is the time visible to unbound when it conducted the query, which is the system time, which will be (within fractions of a second) the time of the timestamp of the file. Or is there some reason Unbound would have a different idea of the current Unix epoch timestamp to the value exported by the OS? > Parsing last success seems like the most straightforward approach. The > first entry is a seconds since epoch so that should be readily > supported. I want to suggest using something like the average of > last_success and next_probe but I am unable to come up with a clear > rationale. I prefer to avoid having time go backwards if at all feasible. So the approach is, "if the time that Unbound last updated is newer than my current time, step the time forward far enough that, at least then, DNSSEC would validate, then try DNS. If that works, with validation on, great; if it doesn't, fall back to Checking Disabled. Once we have time-server IPs, step time forward _again_ with ntpdate, then let the ntpd startup script fix things." (And yes, for the other folks reading: I know that ntpdate is bad compared to ntpd with maintained drift-files and battery-backed system clocks, but this is entirely for a system with no battery-backed clock) -Phil _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
