Network Time Protocols and Resolving no server suitable for synchronization found From ntpdate

Last updated: January 24, 2024

1. Introduction

Network time protocols rely on external servers to ensure an accurate setting of the operating system clock. However, time protocol clients may sometimes be unable to fetch the current date and time due to different problems.

In this tutorial, we talk about network time protocols and ways to ensure their proper function. First, we begin with a general description of time protocols. Next, we install one of the common time protocol packages. After that, we test and configure the newly installed package. Finally, we go over some common errors during synchronization.

For brevity, unless explicitly indicated, we use NTP as a general term for any time protocol.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Time Protocols

The idea behind time protocols is to provide stable communication between servers that have the current accurate time and clients or client servers that require it.

2.1. Network Time Protocol (NTP)

The original pure Network Time Protocol (NTP) as defined by RFC 5905 – Network Time Protocol Version 4 is a UDP-based protocol to get the accurate date and time from a trustworthy source. In short, we use an NTP client (default port 1023) to send requests to a time synchronization server (default port 123):

  +-----------------------------+
  |                             |
  | Network Time Protocol (NTP) |
  |           Server            |
  |                             |
  +-----------------------------+
           ^        |123
       1023|        v
         +------------+---+
         | NTP Client |   |
         |------------+   |
         | NTP Daemon |   |
         |------------+   |
         |       NTP      |
         +----------------+
         |                |
         |  Linux System  |
         |                |
         +----------------+

In its essence, the mechanism is similar to DNS: based on the guidance of a daemon, a client sends requests to a server, which responds with the correct current data. Further, just like DNS and dig, NTP packages usually contain a manual query tool.

However, the implementation of NTP also involves some specifics to ensure stability:

  • avoid clock drift
  • correct for leap seconds
  • recover from crashes
  • avoid skipping seconds
  • optionally verify the server

If any of these mechanisms fail, we might experience an error.

2.2. Simple Network Time Protocol (SNTP)

A simplified version of NTP is the Simple Network Time Protocol (SNTP) as defined in RFC 4330 – Simple Network Time Protocol (SNTP) Version 4.

In general, SNTP has several main differences when compared to NTP:

  • uses only one server
  • no security features
  • no server selection based on the accuracy
  • no backup servers
  • works with fixed intervals
  • might skip seconds

These characteristics make the protocol faster and easier to implement but less accurate than pure NTP.

2.3. Network Time Security (NTS) and Network Time Protocol Security (NTPsec)

Since clocks are vital in many applications, such as encryption and identification, NTP can play a critical role when it comes to security.

So, also similar to the DNS path through DNSSEC, the RFC 8915 – Network Time Security for the Network Time Protocol (NTPsec) codifies a number of extensions that make NTP more secure, hindering attacks against network time servers and clients:

  • keys
  • certificates
  • identification

For example, securing the NTP communication means a potential attacker won’t be able to pose as a legitimate NTP server by, e.g., replacing the current DNS entry with their own IP address. Further, packet tampering in Man-in-the-Middle (MitM) incursions would just lead to dropping instead of incorrect times.

Unlike NTP, the port for NTPsec is 4460.

2.4. Strata

Importantly, time protocols have layers, called strata. A stratum shows the level at which a given daemon operates.

For example, if a server gets its time directly from a source such as a high-precision atomic clock, it’s said to be at stratum 0. Servers that use stratum 0 sources are at stratum 1 and so on. Finally, a stratum value of 16 indicates an unsynchronized server.

3. Install NTP Package

Perhaps one of the most common packages with a full NTP implementation is ntp, which provides the Network Time Protocol Project variant:

$ apt-get install ntp

However, this can now also be a transitional package for ntpsec, i.e., NTPsec:

$ apt-get install ntpsec

Still, we can install either via apt.

4. Test and Configure NTP

Although NTP can be quite complex, most implementations work out of the box without further configuration. Still, we can also add custom settings.

4.1. Tests and Queries

First, let’s use a standard utility to check the current ability to synchronize via NTP:

$ ntpq -pcrv
     remote                                 refid      st t when poll reach   delay   offset   jitter
=====================================================================================================
 0.debian.pool.ntp.org                 .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 1.debian.pool.ntp.org                 .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 2.debian.pool.ntp.org                 .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 3.debian.pool.ntp.org                 .POOL.          16 p    -  256    0   0.0000   0.0000   0.0001
 [...]
associd=0 status=0015 leap_none, sync_unspec, 1 event, clock_sync,
leap=00, stratum=2, precision=-23, rootdelay=9.663, rootdisp=119.555, refid=196.66.6.66,
reftime=e9666fed.5200085f 2023-12-12T16:56:07.320Z, tc=6, peer=16662, offset=0.471131,
frequency=26.666044, sys_jitter=0.428282, clk_jitter=0.318834,
clock=e9266601.35689880 2023-12-12T16:56:01.208Z, processor="x86_64",
system="Linux/5.10.0-666-amd64", version="ntpd ntpsec-1.2.2", clk_wander=0.001748,
leapsec="2017-01-01T00:00Z", expire="2023-12-31T00:00Z", mintc=0

Here, we use the fairly universal ntpq tool to query ntpd (NTP daemon) for the current peers, time of the system, and other associated data:

  • -p: print peer list
  • -c: run a command and exit without entering interactive mode
  • rv: internal ntpq command to read system or peer time variables

Should we kill ntpd, e.g., via killall, ntpq wouldn’t be able to return any data:

$ killall ntpd
$ ntpq -pcrv
***Socket error; probably ntpd is not running

***Socket error; probably ntpd is not running

An alternative way to query a specific server manually are the ntpdate and sntp commands:

$ ntpdate 0.fi.pool.ntp.org
2023-12-12 12:00:10.666101 (-0600) +0.005710 +/- 0.048026 0.fi.pool.ntp.org 192.66.101.26 s2 no-leap

Here, we use the NTPsec ntpdate command to extract the current date and time from the NTP server 0.fi.pool.ntp.org. In fact, since the original ntpdate is deprecated and prone to vulnerabilities, this is just a wrapper around ntpdig.

To use sntp, we should first install the sntp package. If we do, we’d get the same output:

$ apt-get install sntp && sntp 0.fi.pool.ntp.org
[...]
2023-12-12 12:00:10.666101 (-0600) +0.005710 +/- 0.048026 0.fi.pool.ntp.org 192.26.105.26 s2 no-leap

Finally, we can also use ntpdig directly:

$ ntpdig 0.fi.pool.ntp.org
2023-12-12 12:12:00.666010 (-0600) -0.001207 +/- 0.036967 0.fi.pool.ntp.org 192.66.101.26 s2 no-leap

It’s usually best to pick a server that’s as geographically near as we can for optimal performance. If we’re satisfied with the results, we can persist our choices in the configuration files.

4.2. Configuration

To set specific parameters, we can configure them in a file within the /etc/ntp.d/ directory or directly within /etc/ntpsec/ntp.conf or /etc/ntp.conf, depending on the implementation:

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
driftfile /var/lib/ntp/ntp.drift

In this case, we configure four NTP servers in a pool and set up a drift file at /var/lib/ntp/ntp.drift. Drift files store a measurement of drift based on the number of processor clock crystal cycles between ntpd runs.

This configuration is fairly minimal, but we can set more options:

  • access control entries that restrict certain servers, protocol settings, or features
  • logging options and statistics
  • specific pool declarations

Again, in most cases, we shouldn’t need to touch the configuration manually.

5. Common NTP Errors

Since ntpdate, even as a wrapper to ntpdig, is still the current manual way to query servers, let’s see what errors it produces, as they are often valid for NTP in general.

Still, we won’t delve into function-specific errors of the tool.

5.1. Parameter Problems

Some errors and warnings stem from problematic parameter values:

  • -e (processing delay to perform authentication): %s: encryption delay %s is unlikely
  • -p (number of samples per server, 1-8): number of samples (###) is invalid
  • -t (maximum wait time for response): timeout ### is undecodeable, usually meaning an invalid value

Although not fatal, misconfiguration here can mean a non-functional query.

5.2. Server Resolution and General Failures

Of course, like with other tools, we can experience some common problems:

  • Error resolving, Exiting, name server cannot be used: unsuccessful name resolution
  • the NTP socket is in use, exiting: the NTP socket might be serving another query at the moment

Naturally, the first issue can be caused by an invalid name server or bad DNS settings, while the second usually means we’re already in the process of using the respective socket.

5.3. Security Errors

When it comes to NTPsec, some problems can arise from the supplied keys:

  • no key file <PATH>, exiting
  • authentication key ### unknown

Both are fairly self-explanatory.

In addition, we can experience a trust problem with the server in the form of Server dropped: Server is untrusted. This means that we can’t verify the identity of the server for one reason or another, mainly due to key malfunction.

5.4. Server Problems

By far the biggest category of errors that NTP synchronization attempts may lead to, relates to the server we contact:

  • rate limit response from server: too many requests in a short time
  • Server dropped: no data: no data received from server after timeout
  • Server dropped: Server has gone too long without sync: similar to a timeout, we can’t rely on the server at this point
  • Server dropped: server too far away: RTT (Round Trip Time) of server too big
  • Server dropped: Leap not in sync: we are out of sync with the remote server
  • Server dropped: server is very broken: ambiguous error that can result from different conditions, including remote misconfiguration or bad implementation
  • Server dropped: strata too high: stratum 16 (or above) servers are unusable

Encountering any of the above situations for each configured or supplied server results in the no server suitable for synchronization found error.

Critically, due to the high amount of DDoS attacks through port 123 and the vulnerable pure NTP protocol, many Internet service providers block both. This means we should either transition to NTPsec on port 4460 or at least change the port (not recommended).

6. Summary

In this article, we explored NTP, SNTP, and NTPsec, as well as some common errors we might experience with such protocols.

In conclusion, although seemingly complex, time-keeping protocols usually come preconfigured and work out of the box.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.