Re: non-working DNSSEC after network outage
"G.W. Haywood" <[email protected]>
| Newsgroups | gmane.network.dns.bind.user |
|---|---|
| Message-ID | <[email protected]> |
Hi there, On Fri, 21 Aug 2026, Mark Andrews wrote: > On 22 Aug 2026, at 07:35, Danny Mayer wrote: > > > Yes it's definitely a chicken and egg problem. When NTP starts up it needs to perform a DNS lookup > > Platforms without a RTC need to do what we did last century to set > the clock at boot. You have a clock file that is touched every > minute and that file?s time is used to set the approximate time at > boot. My experience of the NTPD package (as opposed to the NTP protocol) on machines that either had intermittent network contact or that weren't running 24/7 was so frustrating that I switched everything to Chrony. Must have been nearly two decades ago. Never had cause to regret it. One of its design goals was to handle intermittent network connections and things like laptops. In my experience it handles these very well, as far as I'm concerned it's more or less configure and forget. My nameservers do run 24/7 but the only one that I operate myself runs Chrony too. It's a Virtualbox VM. Occasionally (like every couple of months) the clock goes off the reservation on that machine, by which I mean it goes out by a second or two when everything on the LAN usually sits in a band of a couple of milliseconds and remotes of around 50ms. Chrony can't seem to fix it. That sets off the alarms in Icinga, but even then I see no DNS issues. The clock problem is pretty certainly within Virtualbox. I have to reboot it. For years I've been telling myself that I'll move it over to QEMU when I, er, get a minute. This Linux Foundation blog post on the security of NTP implementations is worth a look, even if it is nearly ten years old: https://www.linuxfoundation.org/blog/blog/cii-audit-identifies-secure-ntp-implementation -- 73, Ged. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.