Joining pool.ntp.org#

Why#

This guide did not use pool.ntp.org as an upstream source: the Chrony chapter prefers explicitly named national metrology laboratories, more predictable to monitor one by one. That choice isn’t just a design preference: as explained further below, it is an eligibility condition for joining the pool as a contributor. The pool nonetheless remains omnipresent across the rest of the Internet, without ever having been explained so far. The NTP Pool Project is a decentralized, volunteer-run network of several thousand NTP servers, made freely available to serve the vast majority of Internet-connected devices (routers, ISP boxes, embedded systems, Linux distributions). Once a Stratum 1 is operational and validated (Final verification chapter), joining it as a contributor is a natural next step: a now-reliable server can serve thousands of other machines worldwide instead of staying reserved for its own domain.

How the pool works#

Unlike the institutional servers used in the Chrony chapter (each with a fixed, known IP address), pool.ntp.org isn’t a single server but a DNS rotation system: every resolution of pool.ntp.org (or a regional zone like europe.pool.ntp.org) returns a different subset of servers, picked from all active contributors in the relevant geographic zone, weighted by a reliability score continuously computed by a network of monitoring stations distributed worldwide.

  Client                          DNS pool.ntp.org         Contributors
  │                             │                        ┌──────────────────┐
  │ resolves europe.pool.ntp.org                         │ Server A (18)    │
  ├─────────────────────────────►                        ├──────────────────┤
  │                             │ weighted selection:    │ Server B (15)    │
  │                             │ score + geo proximity  ├──────────────────┤
  ◄─────────────────────────────┤                        │ This server (?)  │
  │ 4 different IP addresses,                            └──────────────────┘
  │ different on each lookup

  └──────────────────────────────────────────────────────►
         direct NTP query to one of the returned addresses

This mechanism spreads load across thousands of volunteer contributors instead of concentrating global traffic on a handful of institutional servers, that’s what makes the service free and sustainable at Internet scale.

Eligibility condition: no pool.ntp.org as an upstream source#

The project’s official guide is explicit on this point:

Source: official join guide of the NTP Pool Project

“Servers joining the project should not have pool.ntp.org as their parent server(s), instead they should be configured manually with a few good servers (these can be chosen from the project itself, what is important is that they are statically chosen and not randomly assigned on every restart of the server, this helps giving good quality of service).”

A server can therefore perfectly well pick its upstream sources from among the pool’s members, provided they are named individually and fixed: what the project excludes is depending on pool.ntp.org’s own random DNS rotation as a source, a choice that would change target on every restart and would skew the very quality-of-service measurement that the monitoring network is trying to establish.

This server already meets this condition: the six fixed upstream sources from the Chrony chapter (explicitly named national metrology laboratories, never pool.ntp.org itself) are precisely the kind of static configuration the pool asks of its members.

Joining as a contributor#

Create an account and register the server#

On manage.ntp.org:

  1. Create an account (email verification)
  2. Add the server: public IP address, desired geographic zone(s) (e.g. europe, or a country code like fr)
  3. Set the netspeed, the bandwidth to allocate to the pool’s NTP traffic

Start conservative with netspeed#

Recommended initial setting: the lowest available (a few hundred kbit/s),
raised gradually once behavior has been observed over several days.

The pool automatically adjusts the volume of requests sent to the server based on this declared value, an overly optimistic netspeed can saturate a residential link or a capped data plan.

Pitfalls to avoid#

Joining the pool with an overestimated netspeed can saturate the connection. NTP traffic volume sent by the pool grows with the declared value, on an asymmetric residential link (limited upload), an overly generous setting from day one can degrade other network usage, or even trigger an ISP alert. Starting low and gradually increasing while watching actual usage (bandwidth consumed, CPU load) is the approach recommended by the project itself.

  • Confusing “using the pool as a source” with “joining the pool as a contributor”. Anyone can query pool.ntp.org as a fallback source without any registration, it’s an open public service. But the two approaches are not independent in the other direction: a server that wants to join the pool as a contributor must precisely not have pool.ntp.org as an upstream source (eligibility condition detailed above). This guide preferred named institutional laboratories (Chrony chapter) that already meet this condition. Joining as a contributor, so the server shows up in DNS results served to others, additionally requires the registration described above.
  • Ignoring the reliability score after registering. The pool’s monitoring network continuously queries the server and computes a score. A score that stays persistently below a certain threshold automatically removes the server from rotation, not as a punitive measure, simply to preserve the service quality perceived by pool clients. A prolonged network outage or an undetected synchronization drift (one more reason to rely on acceptance.sh, Final verification chapter) mechanically lowers this score.
  • Opening the firewall to the pool without revisiting rate-limiting. The nftables rules set up earlier (nftables chapter) also apply to traffic coming from the pool, that’s intentional, but check that the chosen thresholds (10 req/s/IP in the guide’s example) stay consistent with the expected request volume once registered, which can be noticeably higher than purely private usage.

Verify#

# DNS resolution: confirms the rotation principle (different results on
# each call, or after TTL expiration)
dig europe.pool.ntp.org

# Once registered, monitor the score and traffic statistics directly on
# manage.ntp.org (per-server dashboard)

After registering, expect several days before request volume ramps up significantly, the system deliberately eases new servers in gradually rather than exposing them to maximum traffic immediately.

📚 Going further

The NTP Pool Project was launched by Adrian von Bidder in January 2003, following a discussion on comp.protocols.time.ntp about the abuse suffered by public stratum 1 servers; it has been maintained and developed by Ask Bjørn Hansen since July 2005. It runs today thanks to donations and volunteer effort from several thousand server operators worldwide, and serves a significant share of global NTP traffic, including many Linux distributions and ISP boxes configured by default against a pool zone. Full documentation and FAQ available at ntppool.org and manage.ntp.org.