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.
Avant toute inscription, le serveur doit cocher quatre cases :
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.L'inscription est gratuite et prend cinq minutes :
europe et global.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ésultat | Impact score | Cause typique |
|---|---|---|
| OK, offset < 75 ms | +1 (progressive vers +20) | Fonctionnement normal |
| OK, offset 75–400 ms | Léger malus | Serveur sous charge ou WAN dégradé |
| Offset > 400 ms | −4 | Sync locale cassée, leap second mal gérée |
| Timeout / pas de réponse | −5 | Firewall, serveur down, net speed dépassé |
| Stratum 16 annoncé | −5 | Dé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.
Le « net speed » déclaré à l'inscription pilote proportionnellement le volume de requêtes que le pool dirige vers le serveur. Cinq paliers :
| Net speed | Requêtes/s typiques | Bande passante sortante moyenne | Profil opérateur |
|---|---|---|---|
| 1 Mbit/s | < 50 | < 4 kbit/s | Particulier, connexion résidentielle |
| 10 Mbit/s | 50–200 | 4–16 kbit/s | Serveur hébergé petit VPS |
| 100 Mbit/s | 500–2 000 | 40–160 kbit/s | Infrastructure pro, VPS confortable |
| 500 Mbit/s | 2 500–10 000 | 200 kbit/s–1 Mbit/s | Datacenter, bande passante dédiée |
| 1 000 Mbit/s | 5 000–20 000 | 500 kbit/s–2 Mbit/s | Opé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.
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.
# /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.
En rejoignant le pool, le serveur devient une cible de trois comportements parasites :
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.
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.
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.confTrois axes à surveiller en permanence sur un serveur du pool :
https://www.ntppool.org/scores/<IP>/log?monitor=*. Alerter sur score < +10.chronyc tracking vers
Prometheus avec le chrony_exporter ou
équivalent. Alerter sur offset > 50 ms ou stratum > 3.nftables ou conntrack. Une courbe qui explose soudainement signale
un vendor lock ou une attaque en cours.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 :