Hayden

This guide covers everything you need to know about NTP (Network Time Protocol)—from basic concepts to configuration and troubleshooting.

If you’ve managed servers long enough, you’ve probably run into this issue at least once: the server clock is off. It might seem like a minor inconvenience—just a few seconds here and there—but in environments like financial trading systems, those few seconds can translate into significant losses.

 

 

1. What Is NTP and Why Does Time Sync Matter?

The Basics of NTP

NTP (Network Time Protocol) is used to synchronize clocks across networked devices. It’s one of the oldest internet protocols, in use since 1985, and the current version (NTPv4) is standardized in RFC 5905.

The concept is straightforward: your system queries an NTP server for the current time and adjusts its clock based on the response. NTP servers always operate in UTC (Coordinated Universal Time), and your system converts it to the local timezone.

Why Accurate Time Matters

Imagine a data center with hundreds of servers, each with a slightly different clock. Here’s what can go wrong:

  • Log correlation becomes impossible: When troubleshooting incidents, mismatched timestamps across servers make root cause analysis a nightmare
  • Kerberos authentication fails: Active Directory rejects authentication if the time difference exceeds 5 minutes
  • SSL/TLS certificate errors: Certificate validation fails when system time is incorrect
  • Financial transaction issues: Stock trades, forex transactions, and other time-sensitive operations require accurate timestamps for legal compliance
  • Distributed system failures: Database replication, file synchronization, and consensus algorithms break down

In regulated industries like finance, compliance frameworks such as MiFID II, SEC Rule 613, and PCI-DSS require accurate timekeeping for transaction records. Time discrepancies can lead to regulatory issues and disputes.

 

 

2. Understanding NTP Hierarchy: What Is Stratum?

NTP uses a hierarchical structure called Stratum levels. Understanding this helps you choose the right NTP servers.

Stratum Description Examples
Stratum 0 Reference clocks (atomic clocks, GPS receivers) Cesium atomic clocks, GPS satellites
Stratum 1 Servers directly connected to Stratum 0 time.nist.gov (NIST), time.google.com
Stratum 2 Servers syncing from Stratum 1 pool.ntp.org servers
Stratum 3 Servers syncing from Stratum 2 Internal corporate NTP servers
Stratum 16 Unsynchronized / unreachable –

Pro tip: For most use cases, Stratum 2 or 3 servers are sufficient. Directly hitting Stratum 1 servers creates unnecessary load, and Stratum 2 servers provide more than enough accuracy.

 

 

3. Public NTP Servers You Can Use

Here’s a list of reliable public NTP servers.

Government & Stratum 1 Servers

Server Address Operator Notes
time.nist.gov NIST (US) Connected to atomic clock
time.windows.com Microsoft Windows default
time.apple.com Apple macOS/iOS default

Major Tech Companies (Stratum 1-2)

Server Address Operator
time.google.com Google
time.cloudflare.com Cloudflare
time.facebook.com Meta
time.aws.com Amazon (for AWS)

NTP Pool Project

If you don’t want to hardcode specific servers, the NTP Pool automatically connects you to nearby, reliable servers.

0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
3.pool.ntp.org

For region-specific pools:

0.us.pool.ntp.org      # United States
0.europe.pool.ntp.org  # Europe
0.asia.pool.ntp.org    # Asia

Check current pool status at NTP Pool Project.

 

 

4. Configuring NTP on Linux: ntpd vs chrony

What’s the Difference?

Linux offers two main options for NTP: the traditional ntpd and the newer chrony. Since RHEL 8, CentOS 8, and Rocky Linux 8, chrony has become the default.

Feature ntpd chrony
Sync speed Slow (minutes) Fast (seconds)
Unstable network handling Poor Excellent
Resource usage Higher Lower
VM environments Time drift issues Handles well
Hash algorithms MD5, SHA1 SHA256, SHA512
Recommended for Legacy systems Modern systems

Bottom line: Use chrony for new deployments. It syncs faster and handles network instability better.

Installing and Configuring Chrony

Step 1: Install Chrony

# RHEL/CentOS/Rocky Linux
sudo yum install -y chrony

# Ubuntu/Debian
sudo apt-get install -y chrony

Step 2: Edit the Configuration File

Config file locations differ by distribution:

  • RHEL/CentOS/Rocky Linux: /etc/chrony.conf
  • Ubuntu/Debian: /etc/chrony/chrony.conf
# RHEL/CentOS/Rocky Linux
sudo vi /etc/chrony.conf

# Ubuntu/Debian
sudo vi /etc/chrony/chrony.conf

Comment out the default servers and add your preferred NTP sources:

# Comment out default pool servers
# server 0.centos.pool.ntp.org iburst
# server 1.centos.pool.ntp.org iburst
# server 2.centos.pool.ntp.org iburst
# server 3.centos.pool.ntp.org iburst

# Add NTP servers
server time.google.com iburst
server time.cloudflare.com iburst
server time.nist.gov iburst
server 0.pool.ntp.org iburst

# Drift file location
driftfile /var/lib/chrony/drift

# Allow large time corrections on startup (first 3 updates, if offset > 1 sec)
makestep 1.0 3

# Sync hardware clock
rtcsync

# Log directory
logdir /var/log/chrony

The iburst option sends multiple packets at startup for faster initial synchronization. Always include it.

Step 3: Start and Enable the Service

# Start the service
sudo systemctl start chronyd

# Enable on boot
sudo systemctl enable chronyd

# Check status
sudo systemctl status chronyd

Step 4: Verify Synchronization

# Check connected NTP sources
chronyc sources -v

# Check detailed sync status
chronyc tracking

chronyc sources output example:

210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.google.com               1   6   377    25   +2696us[+2696us] +/- 20ms
^- time.cloudflare.com           3   6   377    24   +3590us[+3590us] +/- 17ms
^+ time.nist.gov                 1   6   377    26   +1835us[+1835us] +/- 45ms

chronyc tracking output example:

Reference ID    : D8EF2300 (time.google.com)
Stratum         : 2
Ref time (UTC)  : Thu Nov 27 05:30:15 2025
System time     : 0.000012345 seconds fast of NTP time
Last offset     : +0.000002301 seconds
RMS offset      : 0.000037828 seconds
Frequency       : 15.658 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.046 ppm
Root delay      : 0.012934678 seconds
Root dispersion : 0.005541169 seconds
Update interval : 521.2 seconds
Leap status     : Normal

Key indicators:

  • Reference ID: Currently synced NTP server
  • Stratum: Your server’s stratum level
  • System time: Offset from NTP time
  • Leap status: “Normal” means synced; “Not synchronized” means failure

Symbol meanings:

  • * : Currently synced source (best)
  • + : Acceptable alternative source
  • - : Excluded from sync
  • ? : Unreachable

 

 

5. Configuring NTP on Windows Server

Windows Server uses the W32Time (Windows Time) service for time synchronization.

NTP Hierarchy in Domain Environments

In Active Directory environments, time flows through this hierarchy:

External NTP Server → PDC Emulator → Other Domain Controllers → Member Servers/Clients

Important: Configure external NTP sync on the domain controller holding the PDC Emulator role.

Configuring the PDC Emulator

Open an elevated Command Prompt and run:

REM Configure external NTP servers
w32tm /config /manualpeerlist:"time.nist.gov time.windows.com" /syncfromflags:manual /reliable:yes /update

REM Restart Windows Time service
net stop w32time
net start w32time

REM Force immediate sync
w32tm /resync /rediscover

Checking Sync Status

w32tm /query /status

Example output:

Leap Indicator: 0(no warning)
Stratum: 2
Source: time.nist.gov
Reference ID: 0xD2A5C2A0
Last Successful Sync Time: 11/27/2025 2:30:25 PM

If Source shows Local CMOS Clock, the server isn’t syncing with external time sources. Check your configuration.

Standalone (Workgroup) Server Configuration

For servers not joined to a domain:

w32tm /config /manualpeerlist:"time.nist.gov,0x8 time.windows.com,0x8" /syncfromflags:manual /update
net stop w32time && net start w32time
w32tm /resync

The 0x8 flag forces client mode for sync requests. Some NTP servers won’t respond without it.

 

 

6. Building Your Own Internal NTP Server

In enterprise environments, running internal NTP servers is recommended over having every server query external sources directly.

Benefits of Internal NTP Servers

  • Network isolation: Internal servers don’t send NTP requests outside your network
  • Traffic reduction: More efficient than hundreds of servers hitting external sources
  • Consistency: All internal systems reference the same time source

Configuring Chrony as an NTP Server

Add these settings to /etc/chrony.conf:

# Upstream NTP servers
server time.google.com iburst
server time.cloudflare.com iburst
server time.nist.gov iburst

# Allow client access from internal networks
allow 192.168.1.0/24
allow 10.0.0.0/8

# Serve time even if upstream is unavailable
local stratum 10

# Drift file
driftfile /var/lib/chrony/drift

# Logging
logdir /var/log/chrony
log measurements statistics tracking

Restart the service:

sudo systemctl restart chronyd

Firewall Configuration

NTP uses UDP port 123. Open it in your firewall:

# firewalld (RHEL/CentOS)
sudo firewall-cmd --permanent --add-service=ntp
sudo firewall-cmd --reload

# iptables
sudo iptables -A INPUT -p udp --dport 123 -j ACCEPT

# Ubuntu UFW
sudo ufw allow 123/udp

 

 

7. Common NTP Troubleshooting Issues

Issue 1: No Synchronization at All

Symptom: chronyc sources shows all servers with ?

Solutions:

  1. Check firewall: Ensure UDP 123 is open 
    # Test connectivity
nc -u -v time.google.com 123

# Check firewall rules
sudo firewall-cmd --list-all
  2. Verify network connectivity 
    ping time.google.com
traceroute time.google.com
  3. Check DNS resolution 
    nslookup time.google.com

Issue 2: Time Offset Too Large

Symptom: When the time difference exceeds 1000 seconds (~16 minutes), ntpd refuses to sync.

Solutions:

  1. Manually set the time first 
    # Stop chronyd
sudo systemctl stop chronyd

# Manual sync
sudo ntpdate time.google.com

# Restart chronyd
sudo systemctl start chronyd
  2. Use chrony’s makestep directive 
    # /etc/chrony.conf
# Step the clock if offset > 1 second (first 3 updates)
makestep 1.0 3

Issue 3: Windows “Sync Error” Message

Cause: W32Time service issues or firewall blocking

Solution:

REM Re-register the service
net stop w32time
w32tm /unregister
w32tm /register
net start w32time

REM Force resync
w32tm /resync /rediscover

Issue 4: Time Drift in Virtual Machines

Cause: Hypervisor time sync conflicting with guest NTP

VMware solution:

  1. Disable VMware Tools time synchronization
  2. Use guest OS NTP only

Hyper-V solution:

# Disable time sync integration service
Disable-VMIntegrationService -VMName "ServerName" -Name "Time Synchronization"

 

 

8. NTP Security Considerations

Preventing NTP Amplification Attacks

The monlist command on older NTP servers can be exploited for DDoS amplification attacks. In May 2025, Cloudflare mitigated a 7.3 Tbps attack that included NTP reflection.

Hardening configurations:

The syntax differs between ntpd and chrony:

For ntpd (/etc/ntp.conf):

# Restrict external queries
restrict default kod nomodify notrap nopeer noquery

# Allow localhost
restrict 127.0.0.1
restrict ::1

# Allow internal network only
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

For chrony (/etc/chrony.conf):

# Chrony denies by default
# Allow only internal networks
allow 192.168.1.0/24

# Explicitly deny specific IPs if needed
deny 192.168.1.100

Keep NTP Updated

NTP versions 4.2.7 and later have monlist disabled by default. Always run the latest version.

 

 

9. NTP Best Practices for Regulated Environments

Financial systems and other regulated environments have strict time accuracy requirements. Here’s what’s recommended:

Redundant Architecture

                    ┌─────────────────┐
                    │ External NTP    │
                    │ Pool (Stratum 1)│
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
        ┌─────▼─────┐  ┌─────▼─────┐  ┌─────▼─────┐
        │ Internal  │  │ Internal  │  │ Internal  │
        │ NTP Srv 1 │  │ NTP Srv 2 │  │ NTP Srv 3 │
        └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
              │              │              │
              └──────────────┼──────────────┘
                             │
                    ┌────────▼────────┐
                    │   Application   │
                    │     Servers     │
                    └─────────────────┘

Deploy at least 3 NTP servers. With only 2 servers, if one provides incorrect time, there’s no way to determine which one is right—this is called the majority problem.

Monitoring

Use tools like Zabbix, PRTG, Nagios, or Prometheus to continuously monitor NTP sync status. Set alerts when offset exceeds your threshold (e.g., 100ms).

Log Retention

For trading systems and regulated environments, retain NTP synchronization logs separately for audit purposes.

 

 

Wrap-Up

NTP isn’t glamorous, but it’s fundamental infrastructure. Once configured correctly, it runs quietly in the background—but when it breaks, the impact cascades across your entire environment.

Key takeaways:

  • Use chrony on modern Linux systems
  • Configure at least 3 NTP sources
  • Ensure UDP port 123 is open
  • For regulated environments, deploy redundant internal NTP servers

Hope this guide helps you get time sync under control.

References:

 

 

Post Views: 12

Leave a Reply