On Sun, 11 Oct 2020 09:44:48 -0400 Greg Troxel <[email protected]> wrote:
> > Sad Clouds <[email protected]> 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.
