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.
