Distributed systems assume their nodes share a coherent view of time. Log analysis, transaction ordering in distributed databases, TLS certificate expiry validation, and Kerberos ticket lifetime checks all break when clocks drift beyond their tolerance. The cost of misalignment is high enough that time sync is treated as foundational infrastructure rather than an afterthought.
Concrete tolerances vary by service. Kerberos refuses authentication if clocks differ by more than 5 minutes by default. TLS certificates reject use outside their validity window. AWS Signature Version 4 (SigV4) drops requests with timestamps off by 15 minutes or more. These thresholds look generous until a server stops syncing for a few hours, after which every threshold is suddenly close to breaching.
NTP organizes time distribution as a tree. Stratum 0 is a physical reference such as an atomic clock or GPS receiver and is not directly reachable on the network. Stratum 1 servers are directly connected to Stratum 0; Stratum 2 servers sync to Stratum 1, and so on down to Stratum 15. Stratum 16 is the special value meaning "unsynchronized."
This hierarchy lets a small number of high-precision references serve millions of clients efficiently. Each client polls multiple upstream servers and statistically selects the most reliable result. Failure of one upstream does not break synchronization, because clients automatically fall back on alternatives. The tree structure also limits clock drift propagation: a few seconds of skew at Stratum 5 should not propagate worse to Stratum 6.
Network latency is the central challenge in remote time synchronization. NTP exchanges four timestamps: T1 when the client sends a request, T2 when the server receives it, T3 when the server sends the response, and T4 when the client receives it. From these four values, the protocol estimates both the round-trip delay and the offset between the clocks.
The offset is calculated as ((T2 - T1) + (T3 - T4)) / 2, which assumes equal latency in both directions. Real networks are often asymmetric, so NTP performs many measurements and applies statistical filters that throw out outliers. On a LAN, sub-millisecond accuracy is routine; over the public internet, tens of milliseconds is typical and usually more than enough for application needs.
The original ntpd from ntp.org has long history and broad compatibility but a large codebase and slow initial convergence. chrony, developed at Red Hat, performs better on devices with intermittent connectivity (laptops, virtual machines) and reaches accurate sync within seconds of starting. Modern Linux distributions including RHEL 8+ and Ubuntu 20.04+ ship chrony as the default NTP client.
systemd-timesyncd is a minimal SNTP client included with most systemd-based distributions. It provides client-only sync without server functionality, suitable for desktops and lightweight containers where simplicity matters more than precision. In cloud environments, provider-managed sources like Amazon Time Sync Service (169.254.169.123) or Google's smearing NTP servers eliminate setup work and provide reliable synchronization without configuration.
Classic NTP has weak authentication and is vulnerable to man-in-the-middle attacks and reflection-based DDoS amplification. Deliberately shifting a target's clock can bypass TLS certificate expiry checks, defeat token validation, or rewrite log timestamps to obscure malicious activity. Time itself becomes an attack surface, and high-value systems treat NTP integrity as a security control.
Network Time Security (NTS), standardized as RFC 8915 in 2020, adds TLS 1.3-based authentication and integrity checking to NTP. chrony 4.0 and later support NTS, and Cloudflare's time.cloudflare.com is a public NTS-enabled server widely used in production. For systems where time is security-critical, configuring NTS instead of plain NTP closes a class of attacks that has been theoretically known for decades but rarely addressed in practice.
Was this article helpful?