Sad Clouds <cryintothebluesky%gmail.com@localhost> writes: > On Sun, 11 Oct 2020 12:49:16 +0200 (CEST) > Havard Eidnes <he%NetBSD.org@localhost> 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 year. That said, with 8, and named, I have seen trouble after about 4 days of outage. 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: https://en.wikipedia.org/wiki/NetInfo 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