NetBSD-Users archive

[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 <> wrote:

> Sad Clouds <> 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. 

Home | Main Index | Thread Index | Old Index