NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Deprecating ntpdate

The combination of ntpd and sntp now implements the functions of ntpdate. As soon as a few remaining issues with sntp are resolved the ntpdate program will be retired.

The following table describes the existing functionality and what other means provide that functionality. You can always check the original documentation of ntpdate and ntpd for an explanation of command line options.

Related Topics: Sntp Issues, StartingNTP4

Following the table is a discussion area.

ntpdate Flag	sntp Flag	ntpd Flag	What it does	Notes
	-K file		KoD history filename
-e N.N		-q	authdelay
-p N		-q	sys_samples	(What needs to be in the ntp.conf file?)
-a N	-a N	-q	Authentication
	-B secs		Broadcast timeout
-d	-d	-d	debugging mode (implies -q)	sntp -v, or ntpd -q -d (but sets the clock!)
-k file	-k file	-k file	key file
	-b addr		Listen on addr for broadcasts
	-l file		Log to file - is this really useful?
-s			log to syslog	always enabled (divert logging to stdout by -l /dev/stdout)
-o N	-o N	-q	NTP Protocol version	ntpd -q using server option version
-q	default	-q	query/report only, don't set clock (implies -u for ntpdate)	ntpd -q with disable ntp in the configuration file.
-r N			rate	? (Apparently never implemented)
-4	-4	-q -4	Resolve DNS lookups to A records
-6	-6	-q -6	Resolve DNS lookups to AAAA records
	-c name		Send concurrent requests to resolved IPs for name
	-M msec		Slew adjustments less than msec, step adjustments larger than msec.
-B	-s	-q	slew time adjustments	ntpd needs either -x or tinker step 0
-b	-S	-q	step time adjustments	ntpd will slew up to 128ms; if that is not acceptable use tinker step .0001)
-t N.N	-g MSECS		transmit inter-packet gap
-u	default		unpriv port
	-r		Use the NTP reserved port (port 123)
-v			verbose	ntpd is always more verbose than ntpdate

History

Back in the "old days", it was Important to get the system time in the right ballpark before starting ntpd. This was usually done by running ntpdate before starting ntpd. Originally, ntpdate and ntpd used duplicated code to decide what the correct time. Over time, the algorithms (and therefore code) used by ntpd evolved, but the code for ntpdate started to suffer serious bit-rot. It became evident that there were 2 camps using ntpdate, those who wanted to set the time as quickly as possible, and those who wanted to set the time as well as possible. This was still generally "something to do" before starting ntpd.

Out of this experience, two changes happened. One was the creation of the SNTP spec, and the other was fixing ntpd so that the system time "only" needs to be correct to within +/- 68 years.

The former change means we have a way to quickly set the time.

The latter change means there has no longer been a need to set the time before starting ntpd, and we now also have a way (using the -q flag) to use the full capabilities of ntpd to set the time initially, "well" (ie, querying multiple servers, finding a clique, identifying falsetickers).

The combination of these changes allow us to take a fresh look at what needs to be done for various timekeeping needs, and what the best way is to meet these goals.

If you want your system to have accurate time, run ntpd. Start ntpd as early as possible in the boot sequence. When it returns, process all of your non-time-sensitive startup processes. If you have services that need stable time before they begin, at this point run ntp-wait, and if it returns "success" it is safe to start your time-sensitive services.

Pretty much anything else will not give you what you want. If you run sntp or ntpd -gq first, then eventually run ntpd and your other services, while the time will be set correctly between the time of the initial correction and when ntpd is restarted nothing is being done to discipline the clock. In this interim, enough drift could occur that when ntpd is finally started that ntpd would need to step the clock back, an operation that is Bad for databases and things like MailDir filestamps. Far better to just begin with ntpd -g and let ntpd get the time set, and then while the non-sensitive processes are running, ntpd is still able to keep the clock disciplined.

Functionality List

Set the time before running ntpd

It is no longer necessary to set the time before starting ntpd.

Use the -g option to ntpd. The system will need to have the time set to within 68 years (more or less) before starting ntpd.

Run once, set the time "well"

ntpdate cannot do this well. It represents a long-neglected clone of ntpd v2 or v3

Use: ntpd -gq with a ntp.conf which uses iburst on at least one server line and a good drift file, the time should be set "well" in about 11 seconds.

With more recent ntpd servers can be specified on the command line as with ntpdate, allowing a more direct replacement:

ntpd -gqc /dev/null server1.name.net server2.name.org server3.name.com

iburst is implied for servers provided on the command line. -c /dev/null avoids using the default /etc/ntp.conf configuration file, so that servers specified on the command line are the only ones consulted.

Possible hitch: ntpd will step the time adjustment if it is more than 128ms (default). This means that a 128ms adjustment will take 256 seconds to apply. We want an option to step any initial offset, I suspect.

Run once, set the time ASAP

Use: sntp -sS -c poolName or sntp -sS hostname...

Please note that sntp will do about as good a job of setting the clock as ntpdate did - it will set the time to that of the server that responds soonest.

No sanity checking is done to choose the "best" time - sntp uses the timestamp in the first valid response.

Related Bug Reports

• http://bugs.gentoo.org/show_bug.cgi?id=21527 (There are comments in the duplicate bugs too.)

Currently Missing Features

Make sure there is a solution to the problem of ntpd -g taking 256s to apply a 128ms slew at startup.

Previously Missing Features

NTP Communications checking

One thing I am missing is that ntpdate is a perfect tool for quickly checking that NTP communication from a client to a server works. This can be done using an unprivileged source port and therefore is even possible when ntpd is already running on a machine. Using "-q" prevents setting the time.

The unprivileged port feature helps to determine a firewall issue, too.

And, being able to use ntpdate without a config file is helping here, too.

-- HeikoGerstung - 15 Oct 2007

Heiko, what's wrong with sntp servername for this, or ntpq -p servername?

-- HarlanStenn - 14 Feb 2008

Update: By default, sntp will only query (and not set the time). Also by default, sntp will use a random (high-numbered) port. You can use sntp -r hostname to issue the request to hostname using port 123. Note that in this case, your local machine cannot be running anything else on port 123.

Feedback about clock stepping

One missing feature is that ntpd does not show how much the clock was stepped.

-- RuneMagnussen - 07 Jan 2007

Rune, with what arguments does ntpd not show how much the clock was stepped? I believe that information is logged. Also see the -q entry in the table above. It might also be useful if somebody with write privs for the gentoo.org bug you reference above put a link in that report to this page.

-- HarlanStenn - 07 Jan 2007

It is written in the log. It just does not show on stdout. I have searched the Gentoo bugzilla again, but I cannot find it. :-/ I do not think it is an issue. Reading through the bugs it looks like nptdate will not be taken out of Gentoo until ntpd can mimic every detail. I only mentioned it as inspiration or as a wish list for ntpd. Bug submitting Gentoo-users may not be typical users.

-- RuneMagnussen - 08 Jan 2007

On my Debian systems ntpd -gq does return the amount that the clock was stepped:

dumpster:~# ntpd -gq
ntpd: time slew +0.004382s

-- SteveKostecke - 08 Jan

OK, I looked at the code. With -q, ntpd will report the adjustment to stdout, and it has been this way since 31 March 2001.

-- HarlanStenn - 09 Jan 2007

I just tried it. It works. It must have been an iniscript-issue. Case closed.

-- RuneMagnussen - 09 Jan 07