# Why the nts-servers Project Provides Configurations for Both chrony and ntpd-rs

> The nts-servers project offers dual configurations for chrony and ntpd-rs, simplifying Network Time Security adoption for diverse NTP client users.

- Repository: [Jauder Ho/nts-servers](https://github.com/jauderho/nts-servers)
- Tags: internals
- Published: 2026-03-04

---

**The nts-servers repository maintains dual-format configuration files to support the two most widely deployed NTS-capable NTP clients, ensuring users can adopt Network Time Security without manual format conversion.**

The nts-servers project serves as a curated registry of publicly reachable NTS (Network Time Security) servers. Because the NTP ecosystem supports multiple independent client implementations, the project provides native configuration files for both chrony and ntpd-rs, eliminating the friction of manual translation for system administrators.

## The Rationale for Dual Configuration Support

### Supporting the Dominant Linux NTP Clients

**Chrony** represents the default NTP client for most Linux distributions, including Ubuntu, Debian, Fedora, and Alpine. The nts-servers project includes a [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) file that follows the daemon's native format, where each server line appears as `server <hostname> nts iburst`.

**Ntpd-rs** offers a modern, high-performance Rust implementation designed for minimal footprint environments. The project provides an [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml) file using TOML syntax with `[[source]]` tables specifying `mode = "nts"` and `address = "<hostname>"`.

### Eliminating Manual Configuration Translation

Without dual-format support, users would need to manually convert server lists between configuration syntaxes. The nts-servers project automates this through a single source of truth, ensuring both chrony and ntpd-rs users receive identical, up-to-date server recommendations without syntax errors.

## How the Project Maintains Synchronization Between Formats

### Centralized Source Data in YAML

All server definitions reside in [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml), a YAML file containing server hostnames, locations, operators, and metadata. This centralization prevents divergence between the two configuration formats.

### Automated Conversion via Python Script

The [`scripts/ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/scripts/ntpServerConverter.py) utility reads [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) and programmatically generates both output formats:

- **`generate_chrony_conf()`**: Writes `server <hostname> nts iburst` lines to [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf)
- **`generate_ntp_toml()`**: Writes `[[source]]` blocks with `mode = "nts"` to [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml)

Running the script without arguments updates both configuration files simultaneously, ensuring they remain synchronized with the YAML source.

## Practical Implementation for System Administrators

### Deploying chrony Configuration

```bash

# Copy the generated configuration to the system location

sudo cp chrony.conf /etc/chrony.conf

# Restart the chrony service to apply changes

sudo systemctl restart chronyd

# Verify NTS-secured sources are active

chronyc sources -v

```

The [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) file includes the mandatory `nts` keyword for each server entry, enabling encrypted authentication.

### Deploying ntpd-rs Configuration

```bash

# Install ntpd-rs (Debian/Ubuntu example)

sudo apt-get install ntp-rs

# Copy the TOML configuration to the expected path

sudo cp ntp.toml /etc/ntp.toml

# Restart the service to load the NTS sources

sudo systemctl restart ntp-rs

# Check source status

ntp-rs status

```

The [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml) file structures each NTS server as a separate `[[source]]` table with `mode = "nts"` explicitly set.

### Regenerating Configurations from Source

```bash

# From the repository root, update both formats

python3 scripts/ntpServerConverter.py nts-sources.yml

# This regenerates chrony.conf, ntp.toml, and updates the README

```

This ensures local modifications to [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) propagate to both client formats consistently.

## Summary

- The nts-servers project maintains dual-format configurations to support both **chrony** and **ntpd-rs**, the two dominant NTS-capable NTP clients.
- A **single YAML source** ([`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml)) feeds both formats through the [`ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/ntpServerConverter.py) script, preventing configuration drift.
- **Chrony** uses a plain-text format with `server <hostname> nts iburst` syntax, while **ntpd-rs** requires TOML with `[[source]]` tables and `mode = "nts"`.
- System administrators can deploy either format directly without manual translation, reducing implementation errors and maintenance overhead.

## Frequently Asked Questions

### What is the difference between chrony and ntpd-rs?

Chrony is the traditional NTP client found in most Linux distributions, offering extensive features and broad hardware support. Ntpd-rs is a modern Rust implementation focused on security, minimal resource usage, and single-binary deployment, making it ideal for containers and embedded systems.

### Can I use both configuration files simultaneously on the same system?

No, you should choose only one NTP client per system. Running both chrony and ntpd-rs simultaneously causes port conflicts on UDP 123 and results in conflicting time adjustments. Select the configuration file matching your installed client and disable or uninstall the other daemon.

### How often should I regenerate the configuration files?

Regenerate the files whenever [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) changes in the upstream repository or when you modify your local copy. The project updates the server list periodically to remove unreachable hosts and add new trusted sources. Running [`ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/ntpServerConverter.py) ensures your local configurations reflect these updates.

### Does the nts-servers project verify server availability?

The project maintains the server list through community contributions and periodic validation, though specific uptime monitoring details are not embedded in the configuration files themselves. Users should verify connectivity using their client's status commands (`chronyc sources` or `ntp-rs status`) after deployment.