Subject: Re: rc.d: time synchronization issues at boot time
To: Alan Barrett <firstname.lastname@example.org>
From: Mike M. Volokhov <email@example.com>
Date: 03/16/2005 17:48:32
On Wed, 16 Mar 2005 17:35:34 +0200
Alan Barrett <firstname.lastname@example.org> wrote:
> On Wed, 16 Mar 2005, Luke Mewburn wrote:
> > Does named need "good" time before it starts?
> The signatures and keys used for DNS security contain expiry times,
> validity periods, and such stuff. Absolute time errors of a few seconds
> will probably be fine; time errors of several minutes will probably not
> be fine. For example, see RFC 2845, which suggests a fudge factor of
> 300 seconds to accommodate clock skew between client and server, but the
> actual fudge factor is up to the server or zone administrator, and parts
> of DNSEC other than TSIG will have their own (different) requirements.
> Time steps while named is running will interfere with named's cacheing
> strategy, causing records to be cached for too long or too short a time
> before expiring. Here, errors of even a few minutes are likely to be
> fine. (Records that expire too soon can easily be retrieved again, and
> records that expire a few minutes too late are unlikely to cause much
> > Finally, what other `early' services should have "good time"
> > (i.e, ntpdate) at boot ?
> I suspect that kerberised NFS needs moderately accurate time.
> Apart from anything else, it's nice if log messages are as accurate as
> possible, which implies running ntpdate as early as possible.
But 127.0.0.1 must not be a single name server running on the net (if
so, there is no matter for owner of such system what an order applied at
sratup). Thus, just let ntp stuff trust other nameservers recorded at
resolv.conf - start it as early as possible.