>> Especially since our default ntp.conf lists names that need to be
>> resolved:
> Exactly - and this is where we have the chicken and egg problem.

I don't think that just retarting named after starting ntpd is enough.
You really don't want to kick named until ntpd has synced up and done
any initial time step it's going to.

I wonder if the named folks could be persuaded to make named handle
clockhopping?  (Say, if the time-of-day changes by more than 10% of the
time named thinks it slept, the clock has hopped and named needs to
adjust its cache times and whatnot correspondingly.  With due allowance
for jitter in small sleeps, of course.)  Then you wouldn't need to
restart it.

Alternatively, I wonder if we should provide a time-since-boot
interface for things like named that don't really care what time it is
but do want to do relative timing.  (This interface would be affected
by time slews but not time steps.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B