On Wed, Mar 16, 2005 at 12:28:46PM +1100, Simon Burge wrote:
> Simon J. Gerraty wrote:
> 
> > >Currently there is no explicit dependency ordering between
> > >ntpdate and named, and the order in which they start is
> > >non-determanistic, although generally it seems that named
> > >is started before ntpdate.
> > 
> > I think it more likely that ntpdate depends on named than the 
> > other way around.
> 
> Especially since our default ntp.conf lists names that need to be
> resolved:
> 
> 	server          0.pool.ntp.org
> 	server          1.pool.ntp.org
> 	server          2.pool.ntp.org

Exactly - and this is where we have the chicken and egg problem.
named requires "good time", presumably for TTLs (and I would think
that kdc would need this too), and to get that, we need to go to
a time server and find out what the "good time" is. But we can
only do that when we've resolved the name of the time server.

By "good time", I mean a good enough approximation to "now" such that
TTLs or tickets won't be disrupted by the time being set violently
backwards or forwards by a time sync via ntp or ntpdate.

Luke and I went round this discussion a few times yesterday (it was
my original gripe about ntpdate and named).

It seems that there are a number of ways to fix the root of the problem:

1. write a minimal name resolution service which would just do
lookups, no zone transfer or any of the other things that the
full DNS does. Use this to resolve hostnames before the full
name service is started.

2. bring up dns, resolve the names of the time server, stop dns,
get a good time value from the ntp server, set time, and re-start
dns. Repeat for kdc and whatever else needs good time.

3. forget about problems with time in kdc or named. (I'm not really
serious here)

4. use dotted quads to resolve a time server (I'm not really serious
here either, due to the dynamic behaviour of the ntp pool)

5. some other means I haven't thought of

Regards,
Alistair