On 2014-03-21 at 23:33 -0400, Joseph Swick wrote:
> I've been lurking for several months now on the list and I remember some
> discussion about trying to find acceptable methods for bootstrapping the
> local system time so that DNSSEC would work.

I raised this on the ntp-pool mailing-lists last year, looking for a
solution because of the chicken/egg bootstrap, with suggested approaches
and some trial scripts.  Eg:

  http://lists.ntp.org/pipermail/pool/2013-July/006569.html

For context, I'm currently running OpenWRT; attached is the
/etc/init.d/ntpdate which I'm using.  It relies upon having Python and
dig installed, as I haven't gotten around to building a small C utility
to do just this task, but perhaps the approach is useful enough that
someone else might do so?

In summary: if the current time is less than the timestamp on the
unbound-maintained copy of the root zone trust anchors, then bump the
time up at least that far, because we must be at >= that timestamp, and
this increases the odds that DNSSEC will validate if we haven't been
off-line for too long.

Then, for each hostname in the $STEP_SERVERS list (which could be
taken from ntp.conf or uci config or whatever, but here is just
hardcoded), I try to resolve IPv4 then IPv6, first with DNSSEC left
enabled, and then with DNSSEC disabled via `dig +cd`.  The first dig
command to return results is the one which is used.

The idea is to minimize the potential vulnerability of syncing to a bad
timesource, by using DNSSEC if it's available and works, after making
sure it has a reasonable chance of working if we've just rebooted, and
only if we've been off-line for some time do we fall back to insecure
DNS.

Make sure that the START value is appropriate for your systems; I've
found the OpenWRT defaults to be sufficiently broken that I stomp on
them on reinstall.  I run ntpdate once the network and firewall are up,
but just before ntpd and both of those well before other network
services which might depend upon time.

Regards,
-Phil