<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> The ntp servers queried presently largely are not dnssec signed, so<br>

> the ntp queries<br>
> should succeed (I think?) in the general case. However, for<br>
> robustness, I'd argue for enhancing the ntp startup script to<br>
> temporarily disable dnssec until it gets a valid time, and then<br>
> enabling it. I believe support for running the script was added to<br>
> busybox ntp, the problem  remaining is how to tell dnsmasq about it<br>
> correctly.<br>
><br>
<br>
</div>Ok, part of my issue was probably also that the clock was so far off, it<br>
didn't want to skew to the correct time.</blockquote><div><br></div><div>Something I've done in the past on systems without RTCs is to have the ntp init script loop on calling ntpdate until it gets a valid time, and then switch over to the continuously running ntpd.  Everything that needs the correct time then has to start after ntp.  But with DNSSEC, that's going to push the need to have the ntp servers specified by ip address, not by hostname, or to have them never be secure, or we find a way to have long-lived dnssec entries.  I think raw IP address specification is probably safer than trying to do something like creating an insecure window around dnssec.</div>
<div><br></div><div>-Aaron</div></div></div></div>