Qui interroge un serveur NTP public ? 6 millions d'adresses en 5 jours

Édition de novembre 2026, mesurée du 28 octobre au 2 novembre | Par Richard DEMONGEOT | Publié le 2 novembre 2026 | Temps de lecture : 7 min

Un serveur NTP public ne sait rien de ses clients, sauf leur adresse et le nombre de leurs paquets. Nous avons relevé ces deux informations toutes les heures, pendant cinq jours, sur les 18 serveurs de la flotte NTP RDEM Systems : les 16 Stratum 2 et nos deux Stratum 1, tous dans le pool NTP. Voici ce que ces 117 relevés disent de ceux qui demandent l'heure.

6 millionsd'adresses clientes distinctes, au moins
72 millionsde requêtes NTP, environ 616 000 par heure
37 % → 91 %37 % des adresses IPv4 font 91 % des requêtes IPv4
16 % / 7 %part de l'IPv6 : dans les adresses, dans les requêtes
72 %des adresses n'interrogent qu'un seul de nos serveurs
≈ 5 %des requêtes écartées par la limitation de débit, depuis le 30 octobre

Méthode et limites

  • Un relevé par heure, du 28 octobre 2026 à 10 h au 2 novembre à 6 h (UTC) : 117 relevés, aucun manqué. Chaque relevé lit sur chaque serveur la table des clients de chrony (chronyc clients) et ses compteurs (chronyc serverstats).
  • Un client est actif dans une heure si son compteur de paquets a augmenté depuis le relevé précédent. chrony garde une adresse dans sa table bien après sa dernière requête : sa simple présence ne prouve rien.
  • Les adresses ne sont jamais écrites. Chacune est remplacée à la lecture par une empreinte (HMAC-SHA256) dont la clé est tenue en mémoire vive, jamais sur disque, et sera détruite à la clôture de cette édition : les empreintes ne pourront alors plus être rapprochées d'aucune adresse.
  • Notre propre trafic est retiré : nos serveurs qui s'interrogent entre eux, et nos sondes.
  • Une adresse n'est pas un appareil. Derrière une adresse IPv4 partagée (NAT d'entreprise, CGNAT d'opérateur), il peut y avoir des milliers d'appareils. En IPv6, un même appareil change d'adresse temporaire au fil des jours (RFC 8981) : nous les regroupons donc par préfixe /64. Nous parlons d'adresses, jamais d'appareils.
  • Les chiffres sont des minimums. chrony écrase ponctuellement des entrées de sa table ; un client écrasé qui revient est recréé et compté, mais une partie de l'activité entre deux relevés peut manquer.
  • Une configuration a changé en cours de route. Les 29 et 30 octobre, une nouvelle configuration (sources diversifiées, limitation de débit) a été déployée sur la flotte, avec un redémarrage de chrony sur chaque serveur. Les compteurs sont additionnés de part et d'autre ; la limitation de débit est traitée à part.
  • Nous mesurons nos serveurs, pas le NTP en général. Ce que reçoit un serveur du pool dépend de ses zones (Europe et France pour les nôtres) et de la part que lui attribue le pool.

IPv4 et IPv6 : 16 % des adresses, 7 % des requêtes

Sur la fenêtre, nous avons vu 6 053 669 adresses : 5 078 898 en IPv4 et 974 771 en IPv6. Regroupées par /64, ces dernières font 935 414 clients, soit 6 014 312 clients distincts au total. Chaque jour complet en compte de 1,7 à 1,9 million. Ces adresses ont envoyé 71 901 008 requêtes.

Part de l'IPv4 et de l'IPv6 dans les adresses et dans les requêtesIPv4IPv6AdressesAdresses — IPv4 : 83,9 %83,9 %Adresses — IPv6 : 16,1 %16,1 %RequêtesRequêtes — IPv4 : 92,8 %92,8 %Requêtes — IPv6 : 7,2 %7,2 %
Part de chaque famille d'adresses. Source : recensement de la flotte NTP RDEM Systems, 18 serveurs, 28/10 → 02/11/2026.

L'IPv6 pèse deux fois moins dans les requêtes que dans les adresses : ses clients restent peu. Même regroupés par /64, 91 % des clients IPv6 ne sont vus que pendant une seule heure ; la rotation des adresses temporaires n'explique donc pas tout. Autre particularité : le volume IPv6 d'un serveur varie du simple au septuple d'un jour à l'autre, selon la part que lui envoie le pool. Les chiffres IPv6 d'un jour donné décrivent donc la distribution du pool plus que la demande ; nous ne citons que des moyennes sur la fenêtre.

Clients réguliers et clients de passage

Deux populations se partagent nos serveurs. Les clients ponctuels ne sont actifs que pendant une seule heure sur les 117 : un appareil qui demande l'heure au démarrage, un script, un outil de test. Les clients réguliers reviennent d'heure en heure, typiquement un démon de synchronisation (chrony, ntpd, systemd-timesyncd) qui interroge ses sources à intervalle fixe.

Adresses IPv4 : part des clients ponctuels et réguliers, dans les adresses et dans les requêtesponctuels (une seule heure)réguliers (plusieurs heures)AdressesAdresses — ponctuels (une seule heure) : 62,9 %62,9 %Adresses — réguliers (plusieurs heures) : 37,1 %37,1 %RequêtesRequêtes — ponctuels (une seule heure) : 8,6 %8,6 %Requêtes — réguliers (plusieurs heures) : 91,4 %91,4 %
Adresses IPv4. Un client « régulier » a été actif dans au moins deux relevés horaires.

37 % des adresses IPv4 font 91 % des requêtes IPv4. Les clients réguliers restent en médiane 49 heures entre leur première et leur dernière requête vue. Les ponctuels sont majoritaires en nombre (62,9 %) et presque invisibles en charge : les trois quarts n'envoient qu'un seul paquet. En IPv6, le déséquilibre est plus marqué encore : 9 % de clients réguliers, qui font 74,1 % des requêtes IPv6.

Durée entre la première et la dernière requête vue, par clientune seule heuremoins de 6 h6 à 24 h24 h et plusIPv4 (adresse)IPv4 (adresse) — une seule heure : 62,9 %62,9 %IPv4 (adresse) — moins de 6 h : 4,2 %IPv4 (adresse) — 6 à 24 h : 6,3 %6,3 %IPv4 (adresse) — 24 h et plus : 26,7 %26,7 %IPv6 (/64)IPv6 (/64) — une seule heure : 91 %91 %IPv6 (/64) — moins de 6 h : 3,9 %IPv6 (/64) — 6 à 24 h : 2,5 %IPv6 (/64) — 24 h et plus : 2,6 %
Durée entre la première et la dernière requête vue, bornée par la fenêtre de 117 h. Survolez un segment pour sa valeur.
Durée vueIPv4 (par adresse)IPv6 (par /64)
une seule heure62,9 %91 %
moins de 6 h4,2 %3,9 %
6 à 24 h6,3 %2,5 %
24 h et plus26,7 %2,6 %

Le rythme de la journée

Adresses actives par heure, moyenne sur la fenêtre, heure de Paris0 h : 0 h1 h : 1 h2 h : 2 h3 h : 104 k104 k3 h4 h : 4 h5 h : 5 h6 h : 6 h7 h : 7 h8 h : 8 h9 h : 9 h10 h : 10 h11 h : 11 h12 h : 12 h13 h : 13 h14 h : 14 h15 h : 15 h16 h : 16 h17 h : 168 k168 k17 h18 h : 18 h19 h : 19 h20 h : 20 h21 h : 21 h22 h : 22 h23 h : 23 h
Adresses actives par heure (moyenne des jours de la fenêtre, heure de Paris). Trois heures sont exclues : un relevé hors calendrier le 29 octobre, et l'heure du redémarrage du 30.

Le nombre d'adresses actives suit la journée européenne : environ 104 000 par heure au creux de la nuit (entre 2 h et 4 h), 168 000 au pic de 17 h, soit un facteur 1,6. Les requêtes, elles, ne varient que d'un facteur 1,26 (de 542 000 à 683 000 par heure) : les clients réguliers, qui font l'essentiel du volume, tournent jour et nuit ; ce sont les clients de passage qui suivent les heures de bureau.

La fenêtre couvrait le week-end de la Toussaint, sans creux marqué : en moyenne 147 000 adresses actives par heure le jeudi, 141 000 le vendredi, 140 000 le samedi et 137 000 le dimanche.

Un client, combien de serveurs ?

Le pool répartit les clients en donnant à chaque requête DNS quelques serveurs pris au hasard dans une zone. Vu de notre flotte, la répartition fonctionne : 72,4 % des adresses n'interrogent qu'un seul de nos 18 serveurs en cinq jours.

Nombre de serveurs de la flotte interrogés par adresse1 : 72,4 %72,4 %12 : 14,5 %14,5 %23 à 5 : 9,9 %9,9 %3 à 56 à 16 : 3,0 %3,0 %6 à 1617 : 0,3 %0,3 %1718 : 198 adresses198 adresses18
Nombre de nos serveurs interrogés par une même adresse sur la fenêtre (part des adresses ; pour 18, le nombre d'adresses).

À l'autre bout, 198 adresses interrogent nos 18 serveurs, toutes en IPv6, et sont actives en médiane 116 heures sur 117, avec des milliers de paquets chacune. Ce sont des adresses qui sembleraient être, pour l'essentiel, les moniteurs du pool NTP, le pool public et collaboratif, qui mesurent en continu chaque serveur pour calculer son score : plus d'une centaine de moniteurs suivent chacun des deux serveurs que nous avons vérifiés.

Le petit pic à 17 serveurs a une explication simple : en IPv4, seuls 17 de nos serveurs sont joignables, car ntp-0-gps n'a pas d'adresse IPv4 publique (l'unique IPv4 du site sert ntp-0-gnss). Sur ces 16 320 adresses, environ 1 000 sont actives presque toutes les heures, comme les précédentes. Les autres ne le sont qu'une heure sur deux en médiane, avec peu de paquets : vraisemblablement des adresses partagées par de nombreux appareils, que la rotation du pool finit par envoyer vers chacun de nos serveurs.

NTS : de l'ordre du pourcent

Tous nos serveurs servent le NTS, l'heure authentifiée. Hors notre propre trafic, la part des requêtes clientes authentifiées par NTS est de l'ordre du pourcent. Le pool public pool.ntp.org ne publie pas de NTS : ses zones rendent à chaque résolution une machine différente, tenue par un opérateur différent, alors que le NTS suppose un certificat lié au nom interrogé (voir le NTS de bout en bout). Un client NTS a donc été configuré exprès, avec le nom d'un serveur précis ou d'un pool NTS : notre pool privé, ntp-pool.rdem-systems.com, est configuré en NTS, et un pool NTS public expérimental existe, sectime.org (voir NTS sur chrony).

La limitation de débit

Un serveur public reçoit aussi des clients trop bavards : firmwares qui interrogent en boucle, scripts mal écrits. chrony peut limiter le débit par adresse et cesser de répondre à ceux qui dépassent le seuil. Sur notre flotte, cette limitation a été mise en place pendant la mesure, les 29 et 30 octobre ; nous séparons donc les deux régimes.

Requêtes écartéesAvantAprès
Toutes familles0,03 %4,8 %
IPv40,03 %5,2 %
Selon le serveur0 à 0,1 %2,8 % à 7,1 %

Environ une requête sur vingt est désormais écartée, et presque uniquement en IPv4 : en IPv6, 174 requêtes seulement l'ont été en cinq jours. Nous ne nommons ni adresse ni opérateur. Les comportements en cause et les parades côté opérateur sont décrits dans opérer un serveur du pool.

Ce que nous en tirons

  • La charge vient des démons, le nombre vient des passants. Dimensionner un serveur sur le nombre d'adresses le surestime ; c'est la part de clients réguliers qui fait le débit.
  • L'IPv6 est là, mais de passage. 16 % des adresses, 7 % des requêtes : les clients IPv6 durables restent rares.
  • Le NTS reste une affaire de clients configurés à la main, de l'ordre du pourcent des requêtes.
  • La limitation de débit coûte peu et filtre une requête sur vingt, sans toucher l'IPv6.

Nous referons cette mesure. Chaque édition aura sa section datée sur cette page, et les précédentes resteront en ligne pour comparer.

Sources

Questions fréquentes

Combien de clients interrogent un serveur NTP du pool ?

Sur les 18 serveurs de la flotte NTP RDEM Systems, du 28 octobre au 2 novembre 2026, nous avons compté plus de 6 millions d'adresses clientes distinctes, de 1,7 à 1,9 million chaque jour, pour près de 72 millions de requêtes. Une adresse n'est pas un appareil : derrière une adresse IPv4 partagée, il peut y en avoir des milliers.

Quelle part du trafic NTP passe en IPv6 ?

Sur nos serveurs, l'IPv6 représente 16 % des adresses clientes mais seulement 7 % des requêtes. Même regroupés par /64, 91 % des clients IPv6 ne sont vus que pendant une seule heure, contre 63 % des adresses IPv4.

Quelle part des requêtes NTP est refusée par la limitation de débit ?

Depuis la mise en place de la limitation de débit sur notre flotte les 29 et 30 octobre 2026, environ 4,8 % des requêtes sont écartées (5,2 % en IPv4), de 2,8 à 7,1 % selon le serveur. Avant, presque rien ne l'était. En IPv6, seules 174 requêtes ont été écartées en 5 jours.