Self-Hosted NTP Server Management: Chrony vs NTPsec vs NTPd

Accurate time synchronization is the invisible foundation of distributed systems. From TLS certificate validation to distributed database consistency, log correlation, and security audit trails, every component in your infrastructure depends on synchronized clocks. Running your own NTP (Network Time Protocol) servers gives you control over time source selection, stratum hierarchy, and synchronization accuracy — without relying on public NTP pools that may be unreliable or manipulated. This guide compares three leading open-source NTP implementations — Chrony, NTPsec, and the classic NTPd — focusing on server deployment, management tooling, monitoring, and operational best practices.

Why NTP Server Management Matters

NTP server management goes beyond simply installing a daemon and pointing it at upstream servers. Proper NTP infrastructure design involves:

• Stratum hierarchy — organizing your NTP servers in tiers (stratum 1 connects to atomic clocks/GPS, stratum 2 syncs from stratum 1, etc.) to minimize load on reference clocks
• Source selection and filtering — choosing reliable upstream time sources and configuring algorithms to reject falsetickers (servers reporting incorrect time)
• Clock discipline — tuning parameters for your specific hardware clock quality, network latency, and jitter characteristics
• Monitoring and alerting — tracking offset, jitter, wander, and reachability to detect time source degradation before it impacts applications
• Security hardening — implementing NTP authentication (Autokey, NTS), access control lists, and rate limiting to prevent NTP amplification attacks
• Failover and redundancy — deploying multiple NTP servers with cross-syncing to maintain time accuracy during upstream outages

Chrony

Chrony is the modern default NTP implementation on most Linux distributions, including RHEL, Fedora, Ubuntu, and Debian. It was designed from the ground up to handle the variable network conditions of virtual machines, laptops, and cloud environments better than the classic NTPd.

Stars: 203 (GitLab mirror) | Last updated: April 2026 | License: GPL v2

Key Features

• Fast synchronization — Chrony can synchronize within minutes on first boot, compared to hours for NTPd, making it ideal for ephemeral VMs and containers
• Excellent drift compensation — maintains a drift file that tracks clock frequency error, enabling accurate timekeeping even during extended network outages
• Adaptive polling — automatically adjusts polling intervals based on network conditions and clock stability, reducing unnecessary network traffic
• Hardware timestamping — supports PTP (Precision Time Protocol) and hardware timestamping for sub-microsecond accuracy on compatible network interfaces
• Two daemons — chronyd (server daemon) and chronyc (management CLI) provide clean separation of concerns
• NTP Timestamping (NTS) — supports Network Time Security for authenticated and encrypted NTP exchanges
• Low resource usage — typically uses less than 10MB of RAM and minimal CPU

Docker Compose Deployment

Running Chrony in a container is straightforward, though NTP servers typically run directly on the host for better clock access:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

version: '3.8'
services:
  chrony:
    image: projectchrony/chrony:latest
    container_name: chrony-server
    restart: always
    cap_add:
      - SYS_TIME
      - NET_BIND_SERVICE
    ports:
      - "123:123/udp"
    volumes:
      - ./chrony.conf:/etc/chrony/chrony.conf:ro
      - chrony-data:/var/lib/chrony
    networks:
      - ntp-net
    environment:
      - TZ=UTC

networks:
  ntp-net:
    driver: bridge

volumes:
  chrony-data:
    driver: local

Chrony configuration for a stratum 2 NTP server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# /etc/chrony/chrony.conf

# Upstream time sources (stratum 1 servers)
server time.nist.gov iburst maxsources 4
server time.google.com iburst
server time.cloudflare.com iburst
server pool.ntp.org iburst maxsources 6

# Allow clients from local network
allow 192.168.1.0/24
allow 10.0.0.0/8

# Record the rate at which the system clock gains/loses time
driftfile /var/lib/chrony/drift

# Enable kernel synchronization
rtcsync

# Serve time even if not synchronized to a reference source
local stratum 10

# Specify the directory for log files
logdir /var/log/chrony
log measurements statistics tracking

# NTS (Network Time Security) server configuration
ntstrustedcerts /etc/chrony/nts/certs.pem
noclientlog

# Key file for NTP authentication
keyfile /etc/chrony/chrony.keys

Management commands using chronyc:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Check synchronization status
chronyc tracking

# List time sources with statistics
chronyc sources -v

# Show detailed source statistics
chronyc sourcestats -v

# View NTP server activity
chronyc activity

# Force re-synchronization with upstream servers
chronyc makestep

# Check if the server is serving clients
chronyc clients

# Display server statistics
chronyc serverstats

# Monitor time offset in real-time
chronyc tracking | grep "System time"

Monitoring Chrony with Prometheus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Install chrony exporter
docker run -d --name chrony-exporter \
  -p 9123:9123 \
  --cap-add SYS_TIME \
  superq/chrony_exporter:latest

# Prometheus scrape configuration
# - job_name: 'chrony'
#   static_configs:
#     - targets: ['chrony-server:9123']

NTPsec

NTPsec is a security-focused fork of the classic NTPd, created in response to vulnerabilities and code quality concerns in the original NTP reference implementation. It removes legacy code, reduces the attack surface, and adds security hardening features while maintaining protocol compatibility.

Stars: Part of NTPsec project | Last updated: May 2026 | License: Custom (NTP-style)

Key Features

• Reduced attack surface — NTPsec has removed over 50% of the code from the original NTPd, eliminating unused protocol modes and legacy features that were common vulnerability sources
• NTS (Network Time Security) support — first NTP implementation to support RFC 8915 for authenticated and encrypted time synchronization
• Privilege separation — runs with minimal privileges, dropping root access after binding to port 123
• Memory safety improvements — uses bounds-checked string operations and modern C coding practices to prevent buffer overflows
• Leap second smearing — built-in support for leap second smearing to avoid clock discontinuities that can disrupt applications
• ntpviz — comprehensive visualization and reporting tool for NTP server performance analysis
• Strict access control — granular restrict rules for source and client management

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

version: '3.8'
services:
  ntpsec:
    image: ntpsec/ntpsec:latest
    container_name: ntpsec-server
    restart: always
    cap_add:
      - SYS_TIME
      - NET_BIND_SERVICE
    ports:
      - "123:123/udp"
    volumes:
      - ./ntp.conf:/etc/ntpsec/ntp.conf:ro
      - ntpsec-data:/var/lib/ntpsec
    networks:
      - ntp-net

networks:
  ntp-net:
    driver: bridge

volumes:
  ntpsec-data:
    driver: local

NTPsec configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# /etc/ntpsec/ntp.conf

# Upstream servers
server time.nist.gov iburst
server time.google.com iburst
server time.cloudflare.com iburst
pool pool.ntp.org iburst maxsources 4

# Access control - restrict queries
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict ::1
restrict 192.168.1.0 mask 255.255.255.0 nomodify nopeer

# Drift and log files
driftfile /var/lib/ntpsec/ntp.drift
logfile /var/log/ntpsec/ntp.log
statsdir /var/log/ntpsec/

# Enable statistics
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# NTS configuration (when enabled)
ntske server
ntske cert /etc/ntpsec/nts/cert.pem
ntske key /etc/ntpsec/nts/key.pem

# Leap second smear
leap smear

NTPsec management and monitoring:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Check synchronization status
ntpq -p

# Detailed peer statistics
ntpq -c rv

# Show system variables
ntpq -c sysinfo

# Run ntpviz for visualization
ntpviz -l /var/log/ntpsec/ -d 7

# Generate HTML report
ntpviz -l /var/log/ntpsec/ -d 7 -o /var/www/ntp-report/

# View time offset over the past 24 hours
ntpviz -l /var/log/ntpsec/ -d 1 -g local-offset

# Compare multiple NTP servers
ntpviz -c "server1,server2,server3" -g offset

Classic NTPd

Classic NTPd is the reference implementation of the Network Time Protocol, maintained by the NTP Project. It’s the oldest and most widely deployed NTP implementation, with decades of operational history. While NTPsec and Chrony have surpassed it in many areas, NTPd remains the standard against which other implementations are measured.

Stars: ~737 (GitHub mirror) | Last updated: August 2025 | License: Custom (NTP-style)

Key Features

• Reference implementation — the definitive NTP protocol implementation with the most comprehensive feature set
• Extensive documentation — decades of operational guides, books, and community knowledge
• Wide platform support — runs on virtually every Unix-like operating system, plus Windows
• Complex clock discipline algorithm — sophisticated filtering and selection algorithms that have been refined over decades
• Interleaved mode — supports symmetric active/passive and broadcast/multicast NTP modes
• Autokey authentication — legacy NTP authentication mechanism (being superseded by NTS)
• Large community — extensive mailing lists, bug reports, and community expertise

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

version: '3.8'
services:
  ntpd:
    image: cturra/ntp:latest
    container_name: ntpd-server
    restart: always
    cap_add:
      - SYS_TIME
      - NET_BIND_SERVICE
    ports:
      - "123:123/udp"
    volumes:
      - ./ntp.conf:/etc/ntp.conf:ro
      - ntpd-data:/var/lib/ntp
    environment:
      - NTP_SERVERS=time.nist.gov,time.google.com,time.cloudflare.com
      - NTP_POOL=pool.ntp.org
    networks:
      - ntp-net

networks:
  ntp-net:
    driver: bridge

volumes:
  ntpd-data:
    driver: local

Classic NTPd configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# /etc/ntp.conf

# Upstream time servers
server time.nist.gov iburst
server time.google.com iburst
server time.cloudflare.com iburst
pool pool.ntp.org iburst maxsources 4

# Access restrictions
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Drift file
driftfile /var/lib/ntp/ntp.drift

# Statistics
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# Broadcast/multicast (if needed)
# broadcast 192.168.1.255
# multicastclient 224.0.1.1

# Enable NTP authentication
crypto pw YourSecretPassword
trustedkey 1 2 3
requestkey 1
controlkey 2

NTPd management commands:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Check peer status
ntpq -p

# Display detailed statistics
ntpq -c rv 0

# Show system peer
ntpq -c sysinfo

# View clock status
ntpq -c clockvar

# Force clock step (use with caution)
ntpdate -b time.nist.gov

# Check if ntpd is running correctly
systemctl status ntpd
journalctl -u ntpd --since "1 hour ago"

Comparison Table

Why Run Your Own NTP Servers?

Running internal NTP servers rather than relying exclusively on public NTP pools provides significant operational advantages:

• Reduced external dependency — your infrastructure maintains accurate time even when upstream NTP servers are unreachable. A properly configured stratum 2 server can maintain sub-millisecond accuracy for days without upstream contact using drift compensation.
• Network efficiency — a single internal NTP server can serve hundreds or thousands of clients, reducing external NTP traffic and avoiding rate limiting from public pool servers.
• Compliance requirements — many regulatory frameworks (PCI DSS, HIPAA, SOX) require documented time synchronization with audit trails. Self-hosted NTP servers provide complete visibility into time source selection and synchronization status.
• Security — public NTP servers are vulnerable to spoofing and manipulation attacks. Running your own servers with NTS authentication ensures time data integrity. Internal NTP servers also reduce exposure to NTP amplification DDoS attacks that exploit open public resolvers.
• Performance — internal NTP servers have lower network latency to clients than public servers, improving synchronization accuracy. In distributed systems where clock skew directly impacts transaction ordering and data consistency, this matters.
• Monitoring and alerting — self-hosted NTP servers integrate with your existing monitoring stack (Prometheus, Grafana, Zabbix), enabling proactive alerting on time source degradation. Public NTP usage provides no such visibility.

For network infrastructure management, check our IPAM comparison for tracking NTP server IP assignments. If you need centralized logging with accurate timestamps, our syslog aggregation guide covers the best log ingestion tools. For network time monitoring, the DNS query logging guide provides complementary visibility.

For network infrastructure management, check our IPAM comparison for tracking NTP server IP assignments. If you need centralized logging with accurate timestamps, our syslog aggregation guide covers the best log ingestion tools. For DNS-based time distribution, the DNS query logging guide provides complementary visibility.

FAQ

What is the difference between stratum 1 and stratum 2 NTP servers?

A stratum 1 NTP server connects directly to a reference clock — such as an atomic clock, GPS receiver, or radio time signal. A stratum 2 server synchronizes from one or more stratum 1 servers. Most organizations run stratum 2 servers, as stratum 1 requires specialized (and expensive) hardware. Stratum 2 servers provide sufficient accuracy (typically sub-millisecond) for virtually all enterprise applications.

How accurate can self-hosted NTP servers be?

With proper configuration and reliable upstream sources, self-hosted stratum 2 NTP servers typically achieve 1-10 millisecond accuracy on LAN clients. Over WAN connections, accuracy depends on network latency and jitter — typically 10-100ms. Hardware timestamping with PTP-capable network interfaces can achieve sub-microsecond accuracy, but requires compatible hardware on both server and client.

Should I use Chrony or NTPd for my NTP server?

For most deployments, Chrony is the recommended choice. It synchronizes faster, handles network interruptions better, uses fewer resources, and has superior drift compensation. NTPsec is preferred when security hardening is the primary concern — its reduced attack surface and NTS implementation make it ideal for security-sensitive environments. Classic NTPd is mainly useful for legacy compatibility or when specific protocol features (like broadcast mode) are required.

What is NTS (Network Time Security) and do I need it?

NTS (RFC 8915) provides authenticated and encrypted NTP communication, preventing time spoofing and man-in-the-middle attacks. It’s increasingly important as NTP-based attacks become more sophisticated. Both Chrony and NTPsec support NTS. For internal networks with physical security, NTS may be optional. For any NTP traffic traversing untrusted networks, NTS is strongly recommended.

How do I monitor my NTP server’s health?

For Chrony, use chronyc tracking and chronyc sources -v to check offset, jitter, and source status. For NTPsec, use ntpq -p and ntpviz for historical analysis. For automated monitoring, deploy chrony_exporter (Prometheus) or configure SNMP traps for offset threshold alerts. Key metrics to monitor: current offset (should be < 1ms), jitter (should be < 5ms), and source reachability (all configured sources should show “reach” > 0).

Can I run NTP servers in Docker containers?

Yes, but with caveats. NTP requires the SYS_TIME capability to adjust the system clock, which containers typically lack. Use cap_add: [SYS_TIME, NET_BIND_SERVICE] in your Docker Compose file. For production deployments, running NTP directly on the host OS is recommended for better clock access and more reliable timekeeping. Containerized NTP works well for testing and lab environments.