
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Hi Dysmas,</div><div dir="ltr"><br><div>On Mar 2, 2020, at 01:59, dy1977--- via Unbound-users <<a href="mailto:unbound-users@lists.nlnetlabs.nl">unbound-users@lists.nlnetlabs.nl</a>> wrote:<br></div><div><br></div></div><blockquote type="cite"><div dir="ltr">[...]<br><span></span><br><span>But when I don't have used a card for more than 1 or 2 days (I didn't test the exact threshold), when I start one, I get in a vicious cycle :</span><br><span></span><br><span>The clock is 2 days or more late</span><br><span>All DNS resolutions fail because of this difference</span><br><span><a href="http://ntp.org">ntp.org</a> calls fail</span><br><span>The clock is not updated</span><br><span>All DNS resolutions fail</span><br><span>And so on...</span><br></div></blockquote><blockquote type="cite"><div dir="ltr"><br></div></blockquote><br><div>Dave Knight and I once wrote down some thoughts about the process of bootstrapping a cold validator onto the network. The draft apparently didn't seem very interesting to anybody else and wasn't picked up by the working group, but I think the potential for circular dependencies is worth documenting. </div><div><br></div><div>Our approach was to specify that validation should be disabled following boot until an accurate sense of time was acquired, which is what many people in this thread have suggested. </div><div><br></div><div>If anybody thinks this document is worth resurrecting and would be happy to say so out loud in dnsop, let me know. Perhaps providing greater focus on setting the clock could make this more relevant. </div><div><br></div><div><a href="https://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00">https://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00</a></div><div><br></div><div><br></div><div>Joe</div></body></html>