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

Sad Clouds <> writes:

> On Sun, 11 Oct 2020 12:49:16 +0200 (CEST)
> Havard Eidnes <> wrote:
>> > The question is whether we ought to do something to break this
>> > circular dependency in our default install by specifying one or two
>> > (depending on "minsane" and resiliency conciderations) ntp servers
>> > via IP address?  The issue then becomes "which IP address(es)" and
>> > "how can that scale"?

Historically we have not run a caching resolver by default, and
resolv.conf gets pointed via DHCP to whatever the server hands us.  Or a
user makes a configuration decision.

At least on 9, there is no default unbound config.

I am not running current, so can someone explain concisely the "defualt
install" path that gets us to DNS failing if the time is off?  Is it
truly "user installs, doesn't make any choices"?

Is this about unbound only, or named?  Is it about validating TLS
certificates, or about DNSSEC?

As for ntpd, last I knew both defaulted to off, following NetBSD's
longstanding tradition of not running things unless the user configures
them on.

What is the time frame over which the clock can get wrong to cause
problems?  I think it's reasonable to think about a 2-week outage, but I
don't see any need to accomodate a machine that's been powered off for a

That said, with 8, and named, I have seen trouble after about 4 days of

So, this is a request to explain how a 'default install' has this
problem, or to clarify the problem statement.

>> ...or improve the documentation for potentially RTC-less systems
>> about the rc.conf ntpdate_hosts workaround.

We already have (9, RPI3) a warning:

  [     6.695012] WARNING: no TOD clock present

when there is no RTC (TOD clock).

Arguably this should be exposed via a sysctl, so that people/things
which wish to have workarounds can condition them on lack of time.

That documentation would seem to belong in the place about configuring a
validating resolver.

It's a really interesting question where the workaround should be, in
ntpd config, or in the resolver.

It's also an interesting question if there should be a workaround, from
a security point of view.  I think people are assuming that "works" Is
more important than "follows configured security policy".  It's not
clear that an attack can be distinguished from an incorrect clock.

> If you look at /etc/rc.d/ntpdate script, it checks if "ntpdate_hosts"
> is empty and if yes, attempts to extract hosts from /etc/ntp.conf

Yes, that's longstanding and seems sensible.

> I would suggest adding the following logic:

If we do this, I it really needs to be limited to the case when the
system has no TOD clock.

> 1. Extract hosts and check if they are hostnames and not IP addresses.
> 2. Attempt to resolve each one of them. If they all fail, fall back to
> hardcoded list of IP addresses that point to public NTP servers.
> The hardcoded NTP servers list would need to be something that is not
> likely to have their IP addresses changed and are always available,
> similar to CloudFlare or Google public DNS servers. This is not 100%
> full proof, but should work for any machine that is able to route
> NTP packets to the Internet.

Except that it should only point to servers that are in the ppol, or
have privacy policies not to engage in tracking.   (I really don't know
what's up here; this is just general caution/paranoia.)

> The man page for ntpdate talks about NetInfo support. No idea what this
> is (maybe somehow similar to SRV records?), but if this is enabled, NTP
> server name/IP can be omitted and ntpdate somehow finds suitable one
> automagically. This probably still needs fully working DNS service.

Netinfo is a proprietary Apple thing and it is obsolete.  Perhaps you
could file a bug with the ntpd project to prune it, on the theory that
upstream problems should be solved upsream:

Another approach would be to make the nameserver permissive about
validation failures when it first starts (perhaps by allowing validation
if it would succeed for a time that is within the interval from the
current clock and plus 6 months), only on machines wtih no TOD, until it
gets one or some number of proper validations.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index