Hello, On 2020-10-11 08:47, Sad Clouds wrote:
On Sun, 11 Oct 2020 09:40:36 -0400 Greg Troxel <gdt%lexort.com@localhost> 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 "XXX.netbsd.pool.ntp.org" 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 (9.9.9.9 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.
tl;dr: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 Regards, Jordan [1] https://man.openbsd.org/ntpd [2] https://marc.info/?l=openbsd-tech&m=142363400330522&w=2