[Pool] Pool, time, DNSSEC and startup catch-22
ntp-pool-phil at spodhuis.org
Wed May 29 04:20:32 UTC 2013
On 2013-05-28 at 21:03 -0700, Hal Murray wrote:
> How close does the time need to be for DNSSEC to be happy?
The signatures include start and end times and the current time needs to
be within those. Current practice tends to give a three week window for
a current signature and there should be rollover some time towards the
end of that window (there are operational specs which get more precise).
> I can see two approaches. One would be to use a separate ntp.conf for
> getting off the ground. The cron job would do the DNS lookup or ask the
> server which systems it is using and write a startup ntp.conf with numerical
> IP Addresses. Boot time would run ntpd using that until it set the time,
> then restart ntpd using the normal ntp.conf which used the pool.
Notably, this is in the class of devices which use ntpdate before using
ntpd, so in fact it's simpler. Using my previous suggestion, I just
need to set ntpdate to use IP addresses and leave ntpd.conf using
For those avoiding ntpdate, a more general solution might be to try to
resolve a hostname which we're confident must exist, ideally using
something DNSSEC-aware enough to set the the CD flag in a second query,
so that if a "trusted" hostname resolves with Checking Disabled but
fails to resolve normally, then we assume that the clock is sufficiently
off. It seems that 0.$subpool.pool.ntp.org is a decent candidate for
this, since in the normal case we're about to need that IP address
anyway and in the good case the work degenerates to DNS cache warming.
Or rather: the first hostname in the normal resolution list.
If that does not resolve, assume clock is off and coerce an ntpdate call
to get a "good enough for now" timestamp which gets us close enough to
resolve DNS and find the time servers to get an operationally reliable
> The other concept is how long a system can use a server after it gets an IP
> Address from DNS. I haven't seen a number published for this. The current
> pool code in ntpd keeps using a server until the server stops responding.
> (If you use "server ...pool..." rather than "pool ...pool..." it keeps using
> the response until ntpd gets restarted.)
> Any plan that uses stashed answers from the pool DNS is going to go over any
> sane TTL if a box is powered off for a long time. I think this will be OK,
> but we should add it to the list of rough edges to keep an eye on.
Note that if we can get logic which uses the CD flag and gets a
response, then we can get an IP address at boot time as a "low trust"
value instead of needing cron. In this case, we have to continue to use
DNSSEC first so that if DNSSEC operates then we don't have an attack
vector which can introduce an untrustworthy time source. Then only if
that fails, use CD.
I'm glad that I asked this list first, this is a much better solution,
it just adds to start-up complexity. It's probably worth treating the
Python solution as a prototype and writing an ntp-boottime tool in C if
that works out fine.
More information about the pool