Re: ntpdate(8) and unbound(8) dependencies during boot

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

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
> requirement?


You can make adjustments in unbound.conf

       val-sig-skew-min: <seconds>
       val-sig-skew-max: <seconds>

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.