Opérer un serveur NTP Pool : guide opérateur et retour d'expérience

Par Richard DEMONGEOT | 20 avril 2026 | Temps de lecture : 14 min

Le NTP Pool (pool.ntp.org) est l'infrastructure de synchronisation temporelle sur laquelle repose, sans qu'il le sache, l'essentiel de l'Internet grand public : routeurs domestiques, smartphones, objets connectés, et une large partie des distributions Linux par défaut. Ce réseau de plus de 4 000 serveurs est 100 % bénévole, coordonné depuis 2003 par Ask Bjørn Hansen et une poignée de contributeurs.

Notre page Pourquoi contribuer au Pool NTP couvre les raisons qui poussent à rejoindre le projet. Celle-ci est la suite pratique : comment on opère un serveur du pool en 2026, les pièges rencontrés, et ce qu'il faut dimensionner pour tenir la charge. RDEM Systems opère depuis plusieurs années des serveurs inscrits au pool, dont une grande partie sous son ASN AS206014 et d'autres sur des transits tiers.

1. Prérequis techniques avant de s'inscrire

Avant toute inscription, le serveur doit cocher quatre cases :

  • Adresse IP statique et publique (IPv4 ; IPv6 fortement recommandée). Les zones 2.pool.ntp.org et 3.pool.ntp.org sont statistiquement plus riches en AAAA : contribuer en IPv6 y a un impact disproportionné. Voir aussi notre guide test NTP IPv6.
  • UDP port 123 ouvert bidirectionnellement au firewall et côté FAI, sans rate-limit agressif. Certains FAI grand public filtrent le trafic NTP entrant — un test depuis l'extérieur est indispensable. Notre site frère couvre l'ouverture correcte d'UDP/123 hors rebond (iptables, firewalld, ufw, Windows Firewall).
  • Synchronisation stable sur au moins 4 sources de qualité (Stratum 1 ou Stratum 2 fiables). L'offset local doit rester sous 10 ms en régime stable, idéalement sous 1 ms. Notre montage Raspberry Pi + GPS documente le minimum viable pour un Stratum 1 personnel.
  • Serveur 24/7 avec supervision. Un serveur qui tombe régulièrement verra son score chuter et sera automatiquement exclu du pool pendant les périodes de panne. Prévoir l'alerte sur offset > 100 ms et sur unreachable.

2. S'inscrire sur ntppool.org/manage

L'inscription est gratuite et prend cinq minutes :

  1. Créer un compte sur l'admin panel NTP Pool (manage.ntppool.org).
  2. Ajouter un serveur par son IP publique (pas de hostname — le pool interroge directement l'IP). IPv4 et IPv6 sont gérées séparément : deux inscriptions pour un serveur dual-stack.
  3. Choisir les zones géographiques que le serveur dessert. Par défaut, le pool attribue la zone du pays de l'IP. Un opérateur européen peut étendre à europe et global.
  4. Régler le net speed — la bande passante que vous offrez. Ne pas surestimer : mieux vaut 100 Mbit/s tenus que 1 Gbit/s annoncés et non servis.
  5. Laisser 24 à 48 heures aux monitors pour établir un score initial. Avant score positif, le serveur ne reçoit pas encore de trafic réel.

3. Comprendre le système de score

Plusieurs monitors géographiquement répartis (Europe, Amérique, Asie, Océanie) interrogent chaque serveur inscrit toutes les 10 à 20 minutes. Chaque requête produit un incrément de score selon la réponse :

RésultatImpact scoreCause typique
OK, offset < 75 ms+1 (progressive vers +20)Fonctionnement normal
OK, offset 75–400 msLéger malusServeur sous charge ou WAN dégradé
Offset > 400 ms−4Sync locale cassée, leap second mal gérée
Timeout / pas de réponse−5Firewall, serveur down, net speed dépassé
Stratum 16 annoncé−5Démon non synchronisé chez l'opérateur

Le score global va de −100 (banni) à +20 (excellent). Un serveur avec score supérieur à +10 est inclus dans les réponses DNS du pool proportionnellement à son net speed. Le score est public sur ntppool.org/scores/<IP> et utile pour diagnostiquer les régressions.

Le pool tolère les creux temporaires (entretien, reboot) sans exclusion immédiate. Mais une baisse de score sous +10 fait sortir le serveur des réponses DNS jusqu'à rétablissement.

4. Dimensionner la bande passante et le « net speed »

Le « net speed » déclaré à l'inscription pilote proportionnellement le volume de requêtes que le pool dirige vers le serveur. Cinq paliers :

Net speedRequêtes/s typiquesBande passante sortante moyenneProfil opérateur
1 Mbit/s< 50< 4 kbit/sParticulier, connexion résidentielle
10 Mbit/s50–2004–16 kbit/sServeur hébergé petit VPS
100 Mbit/s500–2 00040–160 kbit/sInfrastructure pro, VPS confortable
500 Mbit/s2 500–10 000200 kbit/s–1 Mbit/sDatacenter, bande passante dédiée
1 000 Mbit/s5 000–20 000500 kbit/s–2 Mbit/sOpérateur avec lien dédié, CPU conséquent

Un paquet NTP fait 90 octets côté UDP (48 octets de payload + 8 UDP + 20 IPv4 + en-tête éventuel). En pratique, la charge CPU reste négligeable même à 20 000 req/s sur un cœur moderne. Le vrai dimensionnement se fait sur la bande passante entrante et la qualité du lien : un réseau avec une latence stable est plus utile au pool qu'un serveur surpuissant derrière une connexion jittery.

5. Configuration chrony en mode serveur public

Le choix entre chrony et ntpd pour un serveur public est structurant — voir quel démon choisir pour un serveur public sur check-ntp.net pour la décision détaillée. La configuration minimale recommandée sur chrony 4.x : 

# /etc/chrony/chrony.conf — serveur NTP public dans le pool

# === Sources amont (au moins 4, diversifiées) ===
server time.cloudflare.com  iburst nts
server nts.netnod.se        iburst nts
server ntp1.ptb.de          iburst
pool   2.pool.ntp.org       iburst maxsources 4

# === Autoriser le trafic public ===
# Accepter les requêtes NTP de tout l'Internet
allow 0.0.0.0/0
allow ::/0

# === Rate limiting pour protéger le service ===
# KoD (Kiss-o'-Death) au-delà de ~4 req/s d'une même IP
ratelimit interval 1 burst 16 leak 2

# === Sécurité ===
# Ne jamais servir nos variables internes
noclientlog
# Désactiver les commandes de contrôle en externe (chronyc reste en local)
bindcmdaddress 127.0.0.1
bindcmdaddress ::1

# === Stabilité ===
makestep 1.0 3
rtcsync
leapsecmode system

# === NTS côté serveur (optionnel mais recommandé) ===
ntsserverkey /etc/chrony/nts.key
ntsservercert /etc/chrony/nts.crt

La directive ratelimit est cruciale : un client qui boucle sur une requête par seconde (symptôme d'un device IoT cassé) peut représenter des kbit/s à lui seul et pénaliser le score pour tous les autres. Le KoD lui signale de ralentir ; les implémentations correctes obtempèrent, les mauvaises continuent mais sur un rythme que chrony ignore.

6. Configuration ntpd / ntpsec alternative

# /etc/ntp.conf — ntpd/ntpsec en serveur public

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server time.cloudflare.com iburst nts
server ntp1.ptb.de iburst

# Restreindre les actions du monde entier
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery

# Localhost a tous les droits
restrict 127.0.0.1
restrict ::1

# Historique leap second
leapfile /usr/share/zoneinfo/leap-seconds.list

# PAS de monlist (amplification DDoS)
# ntpsec désactive mode 6/7 par défaut ; sur ntpd classique :
# disable monitor

Le flag limited active un rate-limit natif ; kod envoie le Kiss-o'-Death aux abusers ; nomodify notrap nopeer noquery bloque toute tentative de reconfiguration à distance. Ne désactivez aucun de ces flags par défaut.

7. Abuse, DDoS et clients mal configurés

En rejoignant le pool, le serveur devient une cible de trois comportements parasites :

7.1 Vendor lock sur une IP hardcodée

Des constructeurs d'équipements grand public (routeurs, caméras IP, télévisions connectées) ont historiquement codé en dur dans leur firmware l'IP d'un serveur NTP spécifique — parfois la leur, parfois celle d'un opérateur tiers pris au hasard. Des millions d'appareils interrogent alors cette IP pour toujours. Cas documentés : le routeur Netgear WNDR vers l'Université du Wisconsin (2003), les NAS D-Link vers poul-henning.kamp.dk (2005). Il n'y a pas de solution propre : filtrer l'IP source dans iptables, ou accepter la charge et envoyer du KoD.

7.2 Amplification DDoS via monlist (historique)

En 2014, ntpd < 4.2.7 exposait une commande monlist (mode 7) qui retournait la liste des 600 derniers clients. Utilisée en attaque reflected, une requête de 234 octets pouvait produire une réponse de ~49 Ko — un facteur d'amplification de 200. Les attaques de février 2014 (CloudFlare, Hearthstone) ont consommé des centaines de Gbit/s. Mitigations : désactiver mode 6 et 7 côté serveur (fait par défaut sur chrony 4.x et ntpsec), ou migrer vers ces implémentations modernes.

7.3 Clients qui ignorent le KoD

Le Kiss-o'-Death est un paquet NTP avec stratum 0 et un code dans refid (RATE, DENY…) qui indique au client de ralentir ou de changer de source. Les clients RFC-conformes obtempèrent. Les mauvais ignorent et continuent. Pour ceux-là : 

# Bannir temporairement une IP abusive (iptables)
iptables -I INPUT -s 203.0.113.42 -p udp --dport 123 -j DROP

# Ou dynamiquement via ipset + fail2ban
# jail chrony_kod dans /etc/fail2ban/jail.d/chrony.conf

8. Monitoring côté opérateur

Trois axes à surveiller en permanence sur un serveur du pool :

  • Score sur ntppool.org. Grattable en JSON via https://www.ntppool.org/scores/<IP>/log?monitor=*. Alerter sur score < +10.
  • Offset local et stratum. Exporter chronyc tracking vers Prometheus avec le chrony_exporter ou équivalent. Alerter sur offset > 50 ms ou stratum > 3.
  • Trafic et abuse. Compter les paquets UDP 123 entrants via nftables ou conntrack. Une courbe qui explose soudainement signale un vendor lock ou une attaque en cours.

9. Ce que RDEM a appris sur le terrain

Retour d'expérience. Nos serveurs opèrent depuis plusieurs années, majoritairement sous AS206014 mais aussi sur des transits tiers, et contribuent au pool NTP à ntppool.org/a/rdem-systems. Quelques leçons qui s'appliquent à tout opérateur sérieux :
  • L'IPv6 est sous-valorisé dans le pool. La proportion de contributeurs v6 reste faible ; un serveur dual-stack bien configuré reçoit une exposition disproportionnée côté v6 — utile pour le pool, utile pour le SEO.
  • Le net speed ment. Un opérateur qui sous-déclare (100 Mbit/s annoncés sur un lien 1 Gbit/s réel) fournit une meilleure expérience : marge de manœuvre en cas de pic, latence stable. Le pool n'a pas besoin d'un record d'affluence, il a besoin de serveurs fiables.
  • La sync amont est le vrai bottleneck. Un serveur pool qui dérive de 50 ms pendant 10 minutes est plus nuisible à l'écosystème qu'un serveur down. Investissez d'abord dans vos sources amont (4 sources diversifiées, NTS quand possible) avant d'augmenter la bande passante.
  • Le KoD protège le pool, pas le serveur. Le rate-limit chrony/ntpd n'empêche pas un abuser de consommer votre bande passante — il l'invite à arrêter. La protection de capacité se fait au niveau firewall.
  • La leap second est un test de contribution. Les opérateurs qui gèrent correctement les événements leap (voir notre page dédiée) conservent leur score. Ceux qui ne les anticipent pas dévissent dans les heures qui suivent.

10. Désinscrire un serveur proprement

Un retrait brutal génère des timeouts côté monitors, ce qui impacte le score des autres serveurs avec lesquels il était listé. Procédure propre :

  1. Décocher les zones géographiques sur ntppool.org/manage. Le serveur sort des réponses DNS dans un délai de quelques heures.
  2. Attendre 48 heures avant de couper réellement le service NTP. Les caches DNS des clients expirent pendant cette fenêtre.
  3. Retirer l'inscription définitive via l'interface — cela efface les scores historiques.
  4. Annoncer le retrait au-delà de deux semaines si vous étiez un contributeur visible.

Ressources et références