Date: Mon, 13 Jun 2016 03:40:43 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 210245] [PATCH] Update etc/ntp.conf to eliminate failure modes and reflect current ntpd functionality Message-ID: <bug-210245-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210245 Bug ID: 210245 Summary: [PATCH] Update etc/ntp.conf to eliminate failure modes and reflect current ntpd functionality Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: easy, patch Severity: Affects Many People Priority: --- Component: conf Assignee: freebsd-bugs@FreeBSD.org Reporter: paul@inetstat.net Flags: mfc-stable9?, mfc-stable10? Created attachment 171362 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D171362&action= =3Dedit Patch for base/head/etc/ntp.conf (revision 301726) head/etc/ntp.conf is significantly outdated in a number of ways, and can re= sult in a system with unsynchronised time or time synchronised to a bad/false source. This has the potential to escalate into a security failure (probab= ly fail-safe, but with an outage) issue for Kerberos, DNSSEC, amongst other things. The most significant issue is that it uses configuration which the official NTP documentation describes as "suboptimal but works with older versions" (http://doc.ntp.org/current-stable/discover.html#pool). The impact of this issue is deceptively serious, as it gives a significant probability of the NTP service becoming entirely non-functional rising with uptime, and a higher probability of a single failure resulting in false tim= e.=20 The NTP Pool is constantly in flux, with servers entering and leaving the p= ool. With FreeBSD's current default configuration of just 3 statically configur= ed random servers, there is a reasonable chance that all 3 randomly picked ser= vers could vanish over extended uptime. The current configuration will only rec= over from vanishing pool servers on service restart or system reboot. Additiona= lly, with only 3 servers configured, losing a single server is a critical issue,= as ntpd can no longer properly identify a server gradually drifting away from = true time (it will recognise that the 2 remaining servers do not agree, but has = lost a very significant portion of its ability to reliably identify the "false ticker"). NTP 4.2.7p22 (2010/04/02) added a new "pool" configuration command to addre= ss these issues. Using a "pool ... preempt" configuration causes ntpd to dynamically manage the pool servers without any operator intervention or service restarts. When a server goes bad or stops responding, this new configuration causes it to automatically be removed from ntpd's peers/associations, and it will automatically try to discover new servers f= rom the configured pools (via new DNS lookups) to maintain the set of servers between "minclock" (default 3) and "maxclock" (default 10). This functiona= lity has been in the NTP source for quite some time now, and seems to be both functional and stable. This patch also removes the obsolete and unnecessary "restrict -6" syntax w= hich ceased to be relevant quite some time ago, and has no business being anywhe= re in a default configuration for NTP 4.2.8. This bug does duplicate bug #201803, but that bug failed to get any long te= rm attention, and I don't have permission to update the impacted version to CURRENT. I believe that there are some significant issues which can be very easily and quickly mitigated here, and that this should be addressed for 11= .0 release (and seriously considered for 9.x and 10.x errata). I am creating a new bug for this so that it is visible as a 11.0 / CURRENT issue, and not l= ost in the noise of old dusty bugs. This patch improves on the patch in the previous bug in two significant way= s: 1) it includes the "preempt" option to fully enable the automatic associati= on management, and 2) it includes 3.freebsd.pool.ntp.org to provide the full breadth of the pool to the automation (it is designed to deal with "too man= y" and keep the best, discard the worst). It also includes a couple of commen= ted examples of the minimal configuration for automated pool usage. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-210245-8>