[Bug 210245] [PATCH] Update etc/ntp.conf to eliminate failure modes and reflect current ntpd functionality

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Jun 13 03:40:43 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210245

            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 at FreeBSD.org
          Reporter: paul at inetstat.net
             Flags: mfc-stable9?, mfc-stable10?

Created attachment 171362
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=171362&action=edit
Patch for base/head/etc/ntp.conf (revision 301726)

head/etc/ntp.conf is significantly outdated in a number of ways, and can result
in a system with unsynchronised time or time synchronised to a bad/false
source.  This has the potential to escalate into a security failure (probably
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 time. 
The NTP Pool is constantly in flux, with servers entering and leaving the pool.
 With FreeBSD's current default configuration of just 3 statically configured
random servers, there is a reasonable chance that all 3 randomly picked servers
could vanish over extended uptime.  The current configuration will only recover
from vanishing pool servers on service restart or system reboot.  Additionally,
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 address
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 from
the configured pools (via new DNS lookups) to maintain the set of servers
between "minclock" (default 3) and "maxclock" (default 10).  This functionality
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 which
ceased to be relevant quite some time ago, and has no business being anywhere
in a default configuration for NTP 4.2.8.

This bug does duplicate bug #201803, but that bug failed to get any long term
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 lost
in the noise of old dusty bugs.

This patch improves on the patch in the previous bug in two significant ways:
1) it includes the "preempt" option to fully enable the automatic association
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 many"
and keep the best, discard the worst).  It also includes a couple of commented
examples of the minimal configuration for automated pool usage.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list