> That dns starts failing if you don't have a correct clock seems to > be a serious brokenness.
Well, I would not use such words, but I would rather say that the introduction of DNSSEC validation requires a semi-accurate clock. That's part and parcel of the specification. > Plenty of embedded devices that might not have a battery backed > clock... Ought such devices to run their own DNSSEC-validating recursive resolver? It's not obvious that it's a wise choice. That said, the new requirement that DNSSEC vlidation imposes reveals that during the startup sequence of NetBSD, we now have what is in effect a circular dependency for those devices which can't keep time on their own: ntpd wants to be able to look up data in the DNS, perhaps via a local recursive resolver started earlier in the startup sequence, while the recursive resolver depends on a sensible clock, so the recursive resolver needs to rely on ntpd (or ntpdate) for setting the time. 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"? Regards, - Håvard
