[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ntpdate(8) and unbound(8) dependencies during boot
On Sun, 11 Oct 2020 09:44:48 -0400
Greg Troxel <gdt%lexort.com@localhost> wrote:
> Sad Clouds <cryintothebluesky%gmail.com@localhost> writes:
> > I don't think this is specifically confined to RTC-less machines.
> > Real hardware and virtual machines can have their clocks set to
> > incorrect time, for various reasons.
> They can, but I see that as basically bugs or operator error.
> > I think default max clock skew for unbound is around 24 hours.
> That seems remarkably unforgiving, and that seems like an unfortunate
> design choice.
> The circularity between time sync and certificate/etc. validation is
> real. But typically certificates have fairly long lifetimes (90 days
> for letsencrypt is the shortest I tend to see), and it has always
> seemed unwise to me, to require clock sync to high accuracy to make
> validation succeed.
> > The workaround can be easily implemented with various settings in
> > rc.conf, so this should probably be documented at the very least,
> > an not just for RPi.
> Probably it belongs in the unbound man page, as unbound seems to be
> the thing that is being unreasonable here.
> Is it reasonable/feasible to have unbound lighten up on the tight time
You can make adjustments in unbound.conf
but what exactly is a reasonable time skew? Ideally you'd want to keep
it as small as possible, otherwise you open yourself to replay attacks,
etc. It's not just unbound, I think any DNS resolver implementing
DNSSEC would have such limits.
Main Index |
Thread Index |