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 2020-10-11 08:47, Sad Clouds wrote:
On Sun, 11 Oct 2020 09:40:36 -0400
Greg Troxel <> wrote:

So, this is a request to explain how a 'default install' has this
problem, or to clarify the problem statement.
Well NetBSD-9 comes with "unbound" which is supposed to replace "bind"
as a recursive/caching name server. If you care about security, then
you will always use DNSSEC and DoT, which (in my opinion) should be
configured by default. Think of it as http vs https and how most people
are now using https by default. Whether NetBSD default install
configures those features, is a completely different matter.

There is a known issue (which is not exclusive to NetBSD, nor to
unbound) that revolves around a circular dependency with ntpdate/ntpd
and DNSSEC. There are several ways to work around this issue. The fact
that NetBSD does not enable DNSSEC by default, should not preclude it
from implementing or documenting a work around.

The default install is relying on "" hostnames
in /etc/ntp.conf for both ntpdate and ntpd. This fails to work
correctly when two conditions occur at the same time:
a) DNSSEC is used and
b) System time is incorrect

as hostnames cannot be resolved, due to DNSSEC signature validation
failures, I think.

This failure is not very obvious and only noticeable when system time
is wrong by some specific value, which depends on the configuration of
the name server (could be minutes or hours or days).

Ideally ntpdate/ntpd should have a backup list of servers that are not
hostnames, but IP addresses and don't require functioning DNS. If this
can be automated via rc scripts, then it's one less thing to remember
for NetBSD users. Could be as simple as adding a few stable IP addresses
to /etc/ntp.conf and then marking hostnames as "prefer".

OpenBSD has already solved the circular dependency issue by doing constraint validation against trusted HTTP/HTTPS servers ( and 2620:fe::fe by default).

"|ntpd| makes efforts to verify and correct the time at boot if constraints are configured and satisfied or if trusted servers or sensors return results, and if the clock is not being moved backwards." [1]

To avoid the chicken and egg problem and issues with ntpd+DNS etc, OpenNTPD does constraint validation against Quad9 which is one of the few sites that has a TLS cert issued to its IP address.

The benefits of this solution are two-fold, namely fixing the chicken and the egg clock problem, as well as helping against NTP MITM issues.

The idea here is that if your DNS and NTP is broken because of lack of an RTC, on boot ntpd can at least get some idea as to what time it is based on the dates it receives in HTTP(S) response headers from trusted sources. Quad9, Cloudflare, Google etc basically anybody with good availability and who you would trust not to mess with their clocks should suffice for constraint validation. If the big boys are all reporting similar times in their HTTP/HTTPS headers, then it should be safe to set the date accordingly at boot.  What's nice about this is that we can use TLS if the clock isn't too out of whack to negotiate a TLS session, and can fall back to HTTP only if necessary. Under normal operating procedures, the HTTP date info is not used to set the clock, its only a last resort. Under normal circumstances the HTTP date info is only used for constraint validation against traditional NTP data.

The other benefit of constraint validation is that we can sanity check the time data we receive over NTP. If the big boys are all saying the date is "A" and the NTP pool is saying its "B", if there's a big enough skew, then it's likely the NTP pool is either lying or being man in the middled.

This solution has greatly helped on my Edgerouter Lites that do not have an RTC. Before these changes were added to ntpd, I had to call rdate from a cron job and/or use ntpd -s otherwise my unbound DoT setup would fail.


1) Have ntp daemon check various trusted http/https servers at boot to sanity check our clock and NTP data (no DNS needed, fall back to HTTP only if clock is too broken to negotiate TLS)

2) Enjoy not having everything break on boot due to unfortunate lack of RTC



Home | Main Index | Thread Index | Old Index