[Pool] Pool, time, DNSSEC and startup catch-22

Hal Murray hmurray at megapathdsl.net
Wed May 29 04:03:09 UTC 2013

[Context is using DNSSEC.]

ntp-pool-phil at spodhuis.org said:
> Because time was so far off, I couldn't resolve the hostnames needed to get
> the IP addresses to sync against. 

This seems like an important enough problem that somebody should come up with 
a clean solution.

How close does the time need to be for DNSSEC to be happy?

One class of solutions would be to get the initial time close enough.  I 
don't see how to make that work on boxes that don't have battery backed 
clocks.  That includes Raspberry Pi.  I suspect there will be lots more boxes 
running real OSes but shaving pennies by not having a battery backed clock.

Even with a battery backed clock, you need a plan to get going with a dead 

ntp-pool-phil at spodhuis.org said:
> How do folks here, providing this public service, feel about a tool which
> can be run from cron, resolves the IPs periodically and puts them live in a
> local unvalidated (".lan") zone and/or rewrites config files, so that the
> hostnames are dynamic at a resolution of about a day, but resolvable without
> needing accurate time? 

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.

Another approach would be to have the local DNS remember quite a few 
addresses from the pool,  (say 25 or 50) and point the only ntp.conf at that. 
 The cron job would update that list.

Note that we would like two TTLs for the way the pool uses DNS.  One is the 
way it's being used now.  The TTL is used by the DNS servers to distribute 
the load.

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.

These are my opinions.  I hate spam.

More information about the pool mailing list