Updated 25 minutes ago
Here's something strange: your computer doesn't actually know what time it is.
It has a clock, yes—a quartz crystal oscillating millions of times per second. But that crystal drifts. Every crystal does. Left alone, your computer's clock would wander minutes per month, eventually hours, eventually becoming useless for anything that depends on agreeing with the rest of the world about when "now" is.
Time isn't data your computer has. It's a consensus your computer maintains with the rest of the world. Port 123 and the Network Time Protocol (NTP) are how that consensus happens—billions of devices checking in, adjusting their clocks, staying synchronized to within milliseconds of each other across the entire Internet.
Why Clocks Agreeing Matters
You might think a clock being a few seconds off doesn't matter much. Then things start breaking in ways that seem to have nothing to do with time.
Security certificates stop working. Every HTTPS connection checks that the server's certificate is valid right now—not expired, not "not yet valid." If your clock is wrong, legitimate websites look fraudulent. Or worse: expired certificates look valid.
Two-factor authentication fails. Those six-digit codes from your authenticator app? They're time-based. The code is only valid for 30 seconds—but which 30 seconds depends on both devices agreeing about when those seconds are. A clock five minutes off means the code your app shows will never match what the server expects. You have the right password, the right phone, the right everything. You're still locked out because your device disagrees with the server about when "now" is.
Distributed systems corrupt themselves. When multiple servers handle the same data, timestamps determine ordering. Which write happened first? Which transaction should win? If servers disagree about time by even seconds, you get impossible states—data that contradicts itself, transactions that appear to happen in the wrong order, bugs that seem to violate causality.
Logs become fiction. After a security incident, you need to reconstruct what happened. Server A logged an event at 14:32:07. Server B logged a related event at 14:31:58. Did B happen before A? Or are the clocks just wrong? With drifting clocks, forensics becomes guesswork.
The Hierarchy of Time
NTP organizes time sources into layers called "strata," creating a pyramid that distributes accurate time from a handful of authoritative sources to billions of devices.
Stratum 0 is where time comes from—atomic clocks, GPS satellites, radio signals from national laboratories. These aren't networked devices; they're physical instruments measuring the actual passage of time through quantum phenomena or signals from space.
Stratum 1 servers connect directly to stratum 0 sources. A GPS receiver on the roof, a cable to an atomic clock—these servers are the Internet's primary time sources, operated by universities, governments, and major providers. One stratum 1 server might serve time to millions of clients.
Stratum 2 servers synchronize with stratum 1 and serve the general public. When you configure your computer to use pool.ntp.org, you're hitting stratum 2 servers—thousands of volunteer-operated machines distributed worldwide.
Stratum 3 through 15 form additional layers, each synchronizing with the layer above. Your laptop is probably stratum 3 or 4, trusting servers that trust servers that trust atomic clocks.
The hierarchy prevents authoritative sources from being overwhelmed. It also provides redundancy—NTP clients query multiple servers and use algorithms to detect which sources are trustworthy. If one server is wrong, the others outvote it.
Why UDP Port 123
NTP uses UDP exclusively—both sending and receiving on port 123. The choice is deliberate.
Time synchronization needs to be fast. TCP's handshakes and acknowledgments introduce delays, and when you're trying to measure time accurately, every millisecond of network delay matters. UDP lets NTP measure the round-trip time of packets precisely, then compensate for network delay when calculating the actual time.
NTP can also tolerate packet loss. If one time query disappears, the client simply asks again. There's no state to maintain, no connection to re-establish. The protocol just keeps asking "what time is it?" and adjusting based on the answers.
The Amplification Problem
NTP's simplicity became a weapon.
The protocol once included a debugging command called monlist that returned information about the last 600 clients. A small request could generate a response 200 times larger.
Attackers exploited this for amplification attacks: send tiny requests to thousands of NTP servers, but forge the source address to be your victim's IP. The servers respond—not to the attacker, but to the victim—with responses vastly larger than the original requests. Traffic floods exceeding 400 Gbps have been generated this way, enough to overwhelm almost any target.
The NTP servers aren't compromised. They're just doing what they were asked. The attacker simply lied about who was asking.
Modern NTP servers disable monlist by default (fixed in version 4.2.7p261), and administrators should verify their servers don't respond to this command. Rate limiting and firewall rules that restrict NTP queries to trusted sources prevent infrastructure from being weaponized.
The Trust Problem
Original NTP had no authentication. Clients simply trust whatever time servers tell them.
This is fine when the network is trustworthy. It's not fine when attackers can intercept traffic. A malicious actor who controls the network path can feed you false time—making certificates appear valid or invalid at will, manipulating audit logs, undermining time-based authentication.
Network Time Security (NTS) adds cryptographic authentication to NTP. Clients verify they're talking to legitimate servers and detect if anyone has tampered with the time synchronization messages.
NTS uses TLS to establish initial trust, then authenticates subsequent time updates with AEAD (Authenticated Encryption with Associated Data)2. It solves the man-in-the-middle problem that plagued NTP for decades.
Adoption is growing in 2025—Cloudflare offers public NTS services3, major vendors like IBM and Juniper have added support, and implementations like chrony include NTS by default. But most devices and public servers still use unauthenticated NTP. The transition is happening; it's not complete.
Running Time Well
Configure at least three NTP sources, preferably four or more. NTP's algorithms detect outliers, but they need enough sources to identify which server is wrong. Two servers that disagree give you no way to know which is right. Three servers let you outvote the broken one.
For critical infrastructure, consider running internal stratum 1 or 2 servers synchronized to GPS. This reduces dependence on public Internet time and gives you control over accuracy.
Monitor synchronization status. Clock drift is invisible until things break—authentication failures, certificate errors, logs that don't correlate. Alert when drift exceeds thresholds or synchronization fails entirely.
The Consensus Beneath Everything
Port 123 carries something more fundamental than data. It carries agreement—billions of devices constantly negotiating a shared understanding of when "now" is.
That consensus is invisible until it fractures. Then everything that secretly depended on clocks agreeing—security, authentication, databases, logs—starts failing in ways that look unrelated to time.
NTP has been maintaining this consensus since 1985. The protocol is older than most of the systems that depend on it. The stratum hierarchy, the UDP efficiency, the algorithms for detecting unreliable sources—all of it exists to solve a problem so fundamental we forget it exists: making independent clocks agree on a shared fiction of time.
When that fiction holds, everything works. When it doesn't, reality starts to break.
Frequently Asked Questions About NTP and Port 123
Sources
Sources
Was this page helpful?