La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: vivien le 23 janvier 2022 à 22:43:15
-
DNS : Pourquoi certains PC continuent de faire des requêtes sur les anciennes IP, plusieurs jours après la mise à jour DNS ?
Je gère le serveur de mise à jour Ubuntu pour la France https://fr.archive.ubuntu.com/ qui est utilisé par environ 1 million de machine (PC / Serveur / machine virtuelle) normalement situés en France.
Lors de mes précédent changement de serveur, j'ai vu que l'ancienne IP reçois toujours des requêtes encore un an après, alors que le serveur n'héberger plus aucun miroir Ubuntu depuis 1 ans.
Je me suis demandé d'où vient le problème. Le 11 novembre 2021 j'ai migré le serveur chez Scaleway (merci le Scaleway's Open Source Program) tout en laissant le serveur Bouygues Telecom fonctionner (j'ai du supprimer /pool/multiverse faute de place sur le disque).
En quelques minutes le trafic à basculé sur le nouveau serveur. Le lendemain le trafic était très faible toutefois il restait des requêtes réalisées par un milliers d'IP sur le serveur Bouygues, je me suis penché sur ces requêtes pour essayer de percer le mystère.
Première étape : isoler les requêtes réalisées par de vrais PC pour se mettre à jour et exclure tout le trafic autre. En effet, je vois que certains ping en http ce serveur pour de la supervision. Dans ce cadre il peut être intéressant de rentrer l'IP en dure et de ne pas faire de requête DNS.
Dans les données ci-dessous, j'ai donc supprimé tout le trafic qui ne vient pas avec le bon user-agent ou qui a un comportement anormal (on ne télécharge par directement Firefox, il y a des fichiers à mettre à jour avant de pouvoir télécharger une mise à jour). Je n'ai pas précisé, mais tout le trafic est en http (il y a peu de trafic https pour les mises à jour, c'est optionnel pour les clients qui souhaitent chiffrer les échanges et je n'ai pas vu de trafic https sur le serveur restant alors que le certificat https était encore valide)
Les données détaillées jour par jour sont dans un fichier Libre Office Calc : 202201_etude_lenteur_maj_dns.ods (https://lafibre.info/testdebit/ubuntu/202201_etude_lenteur_maj_dns.ods)
Voici la synthèse des requêtes du 12 novembre 2021 au 7 janvier 2022 : 517 IP ont eu un trafic légitime que j'ai synthétisés en 7 colonnes :
- IPv4 / IPv6 : IP d'où vient la requête, j'ai anonymisé la fin de l'IPv4 ou des 64 premiers bits d'une IPv6.
- Version d’Ubuntu : En regardant les fichiers demandés, on peut en déduire la version d'Ubuntu utilisée. Sur certaines IP on voit plusieurs versions, car il y a visiblement plusieurs PC / Serveurs / VM qui utilisent cette même IPv4 publique pour faire les mises à jour. Je pensais que les requêtes proviendrait majoritairement d'une version d'Ubuntu qui a un bug, mais force de constater que ce n'est pas le cas : C'est plutôt équitablement réparti entre version d'Ubuntu (la répartition n'est pas si éloigné de la répartition des requêtes que je reçois sur le serveur Scaleway) :
- 41 IP ont fait des requêtes pour Ubuntu 21.10
- 11 IP ont fait des requêtes pour Ubuntu 21.04
- 3 IP ont fait des requêtes pour Ubuntu 20.10
- 170 IP ont fait des requêtes pour Ubuntu 20.04 LTS
- 192 IP ont fait des requêtes pour Ubuntu 18.04 LTS
- 38 IP ont fait des requêtes pour Ubuntu 16.04 LTS
- 44 IP ont fait des requêtes pour Ubuntu 14.04 LTS
- 33 IP ont fait des requêtes pour Ubuntu 12.04 LTS
- 2 IP ont fait des requêtes pour Ubuntu 10.04 LTS
- HTTP/1.1 ou HTTP/1.0 ? Il y a seulement 3 IPv4 qui font des requêtes en HTTP/1.0, j'imagine à cause d'un proxy situé sur le réseau d'une entreprise (si vous avez une autre idée, je suis preneur, même sur lafibre.info, je vois du trafic HTTP/1.0)
- AS : Numéro d'AS pour identifier le réseau. Je pensais que les requêtes proviendrait majoritairement d'un opérateur qui a un problème sur son DNS, mais force de constater que ce n'est pas le cas : C'est plutôt équitablement réparti entre opérateur.
- Nom de l'AS ou de la plage IP (permettant dans certains cas d'être plus précis, par exemple d'avoir l'université sur l'AS de Renater)
- Supposition DNS :
- "DNS en retard 48h" est utilisé pour les 129 IP qui ont fait des requêtes le 12 novembre 2021 et pas les jours suivants. On peut supposer que le serveur DNS utilisé par ces PC avait un cache modifié pour avoir une grande durée de validité : il a fini par se mettre à jour.
- "DNS pas mis à jour" est utilisé pour les 388 IP qui ont eu du trafic après le 12 novembre 2021, plus de 40 heure après la mise à jour DNS. En observant le trafic jour après jour (voir tableur Calc), on voit que le trafic ne diminue peu. Le 13 novembre 2021 et les jour suivant on avait environ 140 IP distinctes qui réalisaient des requêtes de mise à jour sur l'ancien serveur. Début 2022, on était encore à 100 IP distinctes par jour à faire ces demandes.
- Total requêtes : C'est le total des requêtes entre le 12 novembre 2021 au 7 janvier 2022 que j'ai vu IP par IP. Un même serveur doit faire plusieurs requêtes pour vérifier la présence de mises à jour et il en fait encore plus si il y a des éléments à mettre à jour. Toutefois le volume important et régulier sur certaines IP montre qu'il y a clairement de nombreux PC / Serveur / VM derrière cette unique IP qui font des vérification de la présence de mise à jour mais qui ne téléchargent rien. (Vert: moins de 40 requêtes - Jaune: 40 à 200 requêtes - Orange: 200 à 600 requêtes - Rouge: plus de 600 requêtes)
(https://lafibre.info/testdebit/ubuntu/202201_etude_lenteur_maj_dns.png)
Je ne détaille pas la création de ce fichier, mais certaines actions ont pu être scriptées, d'autres sont manuelles. J'ai bien utilisé la fonction "=RECHERCHEV(A2;[sélection];2;0)" de Calc pour permettre de mettre les fichiers issues de mes script dans un unique tableau Calc.
-
Si vous connaissez la cause de ces requêtes qui vont des mois durant se faire sur l'ancienne IP, je suis preneur.
A noter que l'on voit quelques IPv6 (26 IPv6 contre 491 IPv4) réalisant des requêtes sur les anciennes IPv4/IPv6 du serveur.
IPv6 est donc sous-représenté dans ce problème, mais il est quand même présent.
Dans les connexions habituelles sur le serveur (là aussi en filtrant uniquement sur le trafic légitime), on a 20% de requêtes réalisées en IPv6, mais comme vous pouvez le voir cela varie fortement selon les versions d'Ubuntu :
(https://lafibre.info/images/ipv6/202111_arcep_barometre_ipv6_ubuntu.png)
-
Bonsoir,
Ne se pourrait-il pas qu'un autre FQDN (oublié ?) pointe également sur ces IPs ? Et que celui-ci ait été diffusé à une époque, et est toujours utilisé par certains aujourd'hui...
A+
-
Tu n'aurais pas un "Glue Record" qui traine au niveau supérieur ?
J'ai cela sur certains domaines.
[edit]
Ce que je vois en IPV4:
philippemarques@MacBook-Pro-de-Philippe MacOS % nslookup fr.archive.ubuntu.com
Server: 192.168.4.1
Address: 192.168.4.1#53
Non-authoritative answer:
fr.archive.ubuntu.com canonical name = ubuntu.lafibre.info.
Name: ubuntu.lafibre.info
Address: 51.158.154.169
philippemarques@MacBook-Pro-de-Philippe MacOS % host 51.158.154.169
169.154.158.51.in-addr.arpa domain name pointer fr.archive.ubuntu.com.
philippemarques@MacBook-Pro-de-Philippe MacOS % whois -h whois.ripe.net 51.158.154.169
inetnum: 51.158.128.0 - 51.158.255.255
netname: ONLINE_NET_DEDICATED_SERVERS
country: NL
admin-c: MM42047-RIPE
tech-c: MM42047-RIPE
status: LEGACY
mnt-by: ONLINESAS-MNT
created: 2019-05-06T11:58:01Z
last-modified: 2019-05-06T11:58:01Z
source: RIPE
person: Mickael Marchand
address: 8 rue de la ville l'eveque 75008 PARIS
phone: +33173502000
nic-hdl: MM42047-RIPE
mnt-by: MMA-MNT
created: 2015-07-10T15:02:32Z
last-modified: 2016-02-23T12:43:25Z
source: RIPE # Filtered
% Information related to '51.158.128.0/17AS12876'
route: 51.158.128.0/17
descr: SCALEWAY
descr: Amsterdam, Netherlands
origin: AS12876
mnt-by: MNT-TISCALIFR
created: 2019-10-03T15:09:09Z
last-modified: 2019-10-03T15:09:09Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.102.2 (ANGUS)
philippemarques@MacBook-Pro-de-Philippe MacOS %
philippemarques@MacBook-Pro-de-Philippe MacOS % nslookup
> set all
Default server: 192.168.4.1
Address: 192.168.4.1#53
Set options:
novc nodebug nod2
search recurse
timeout = 0 retry = 3 port = 53 ndots = 1
querytype = A class = IN
srchlist =
> set q=any
> fr.archive.ubuntu.com
Server: 192.168.4.1
Address: 192.168.4.1#53
Non-authoritative answer:
fr.archive.ubuntu.com canonical name = ubuntu.lafibre.info.
Authoritative answers can be found from:
>
> set all
Default server: 213.186.33.99
Address: 213.186.33.99#53
Set options:
novc nodebug nod2
search recurse
timeout = 0 retry = 3 port = 53 ndots = 1
querytype = A class = IN
srchlist = openstacklocal
> set q=any
> fr.archive.ubuntu.com
Server: 213.186.33.99
Address: 213.186.33.99#53
** server can't find fr.archive.ubuntu.com: NOTIMP
> fr.archive.ubuntu.com.
Server: 213.186.33.99
Address: 213.186.33.99#53
** server can't find fr.archive.ubuntu.com: NOTIMP
> fr.archive.ubuntu.com.
Server: 213.186.33.99
Address: 213.186.33.99#53
** server can't find fr.archive.ubuntu.com: NOTIMP
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> fr.archive.ubuntu.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
fr.archive.ubuntu.com canonical name = ubuntu.lafibre.info.
Authoritative answers can be found from:
>
L'ennui doit être de ce côté ( modulo les serveurs, celui-ci n'est qu'un exemple):
> fr.archive.ubuntu.com.
Server: 213.186.33.99
Address: 213.186.33.99#53
** server can't find fr.archive.ubuntu.com: NOTIMP
> fr.archive.ubuntu.com.
Server: 213.186.33.99
Address: 213.186.33.99#53
Vois avec canonical :
** server can't find Address:: NXDOMAIN
> server 192.168.0.254
Default server: 192.168.0.254
Address: 192.168.0.254#53
> set all
Default server: 192.168.0.254
Address: 192.168.0.254#53
Set options:
novc nodebug nod2
search recurse
timeout = 0 retry = 3 port = 53 ndots = 1
querytype = A class = IN
srchlist =
> set q=any
> fr.archive.ubuntu.com
Server: 192.168.0.254
Address: 192.168.0.254#53
Non-authoritative answer:
fr.archive.ubuntu.com canonical name = ubuntu.lafibre.info.
Authoritative answers can be found from:
> server
Default server: 192.168.0.254
Address: 192.168.0.254#53
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> fr.archive.ubuntu.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
fr.archive.ubuntu.com canonical name = ubuntu.lafibre.info.
Authoritative answers can be found from:
ubuntu.com nameserver = ns2.canonical.com.
ubuntu.com nameserver = ns3.canonical.com.
ubuntu.com nameserver = ns1.canonical.com.
ns1.canonical.com internet address = 91.189.94.173
ns2.canonical.com internet address = 91.189.95.3
ns3.canonical.com internet address = 91.189.91.139
>
-
Ne se pourrait-il pas qu'un autre FQDN (oublié ?) pointe également sur ces IPs ? Et que celui-ci ait été diffusé à une époque, et est toujours utilisé par certains aujourd'hui...
Les ancien FQDN ont bien été migrés.
Tu n'aurais pas un "Glue Record" qui traine au niveau supérieur ?
J'ai cela sur certains domaines.
Comme c'est juste un CNAME que met en place canonical sur fr.archive.ubuntu.com qui pointe sur ubuntu.lafibre.info, je ne vois pas.
Les IP ne sont présentes que sur le DNS lafibre.info pas chez Canonical.
$ dig fr.archive.ubuntu.com
; <<>> DiG 9.16.15-Ubuntu <<>> fr.archive.ubuntu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16322
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;fr.archive.ubuntu.com. IN A
;; ANSWER SECTION:
fr.archive.ubuntu.com. 57 IN CNAME ubuntu.lafibre.info.
ubuntu.lafibre.info. 245 IN A 51.158.154.169
;; ADDITIONAL SECTION:
ubuntu.lafibre.info. 57 IN AAAA 2001:bc8:1600:4:63f:72ff:feaf:a2de
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: lun. janv. 24 08:51:36 CET 2022
;; MSG SIZE rcvd: 127
51.158.154.169 et 2001:bc8:1600:4:63f:72ff:feaf:a2de sont bien les nouvelles IP Scaleway.
-
T'inquiètes pas c'est pas lafibre.info, ni toi qui êtes en cause, ni de ta part, ni de Canonical.
Tu pourras pas résoudre ce problème.
-
Hello,
Supposition superfétatoire,
ça pourrait pas être des dnsmasq, pihole, ou autre programme de cache DNS en version obsolète ou buggé ou mal configuré, qui pourrait toujours répondre la même IP ? En particulier valable pour les utilisateurs ayant un routeur openWRT/pfsense/archer/dlink/autre derrière la box de l'opérateur.
-
@vivien, quel était l'ancienne adresse IP ?
-
Anciennes IP : (Bouygues Telecom)
- 194.158.119.186
- 2001:860:f70a::2
Nouvelles IP : (Scaleway)
- 51.158.154.169
- 2001:bc8:1600:4:63f:72ff:feaf:a2de
-
Ici aucun miroir ne pointe vers l'ancienne adresse IP : https://launchpad.net/ubuntu/+archivemirrors
Peut-être d'autres miroirs listés chez les (k|x)ubuntu ?
-
Si l'ancien serveur est encore actif, tu peux demander à Apache de loguer le hostname indiqué dans les requêtes reçues (de mémoire "%{Host}i" dans LogFormat). Tu sauras au moins avec quel FQDN ça arrive...
-
Alors sur tous les serveurs que je gère, je ne répond pas si le hotname n'est pas précisé ou il n'est pas bon : je mets une page vide à la place. Les requêtes http sans hotname ou avec un hostname mauvais sont souvent des attaques.
Là je ne me suis attardé que sur les log du virtualhost avec le bon hostname.
J'ai par acquis de conscience rajoute "%{Host}i" dans les log, juste après l'IP et avant le port destination (80 / 443) :
(https://lafibre.info/testdebit/ubuntu/202201_etude_lenteur_maj_dns_2.png)
Dans ma copie d'écran, on voit bien des requêtes https "(monitoring-plugins 2.2)" qui sont des requêtes de supervision de je ne sais qui (avec peut-être l'IP entrée en dure dans l'outil).
On voit aussi des requêtes de la part de certaines IP qui s’enchaînent et qui montre que c'est un véritable Ubuntu derrière.
Exemple : l'IP 212.166.48.x (IP Belge d'une société qui propose de l’hébergement) télécharge les listes de paquets des référentiels d'Ubuntu 18.04 LTS et les "met à jour" pour obtenir des informations sur les dernières versions des paquets et leurs dépendances à 9h23 et 26 secondes. Il y a ensuite 53 secondes d'attente, probable temps de traitement par le processeur des paquets, puis un téléchargement par cette même IP à 9h24 et 19 secondes des 5 paquets qui sont à mettre à jour. C'est donc un usage légitime et je ne comprend pas que près de 3 mois après le changement d'IP autant de PC continue à utiliser l'ancienne IP. Il y a peu de chance que tous ces utilisateurs aient modifiés leur /etc/hosts pour mettre en dur l'adresse IP.
-
Exemple : l'IP 212.166.48.x (IP Belge d'une société qui propose de l’hébergement) télécharge les listes de paquets des référentiels d'Ubuntu 18.04 LTS
Si tu as du temps "à perdre", ça peut se tenter de les contacter pour essayer d'en savoir plus, non ? Histoire d'avoir une idée plus précise de ce phénomène.
-
Je vois qu'il y a plusieurs IP qui utilisent Apt-Cacher NG (https://www.unix-ag.uni-kl.de/~bloch/acng/), pour maintenir des caches locaux (peut-être des entreprises).
Le code change beaucoup en fonction des versions, je n'ai pas regardé pour celles utilisées ici.
Sur les versions les plus récentes, j'ai l'impression qu'il y a un bug dans le cache.
https://salsa.debian.org/blade/apt-cacher-ng/-/blob/upstream/sid/src/caddrinfo.cc#L427
Au moment de faire la requête, le code ne vérifie pas l'expiration de son cache DNS.
Le seul endroit où elle est testée c'est CAddrInfo::clean_dns_cache, appelé juste avant d'ajouter une nouvelle entrée dans le cache.
Bref, j'ai l'impression qu'il va garder les IP des derniers serveurs contactés tant qu'il n'y a pas de nouveau nom de domaine utilisé (un client qui ajoute une repo APT, ou un nouveau client utilisant un miroir différent).
Pour check_http (monitoring-plugins), le code utilise getaddrinfo, donc soit les utilisateurs ont forcé l'IP quelque part (la configuration de l'outil, /etc/hosts, ...), soit il y a un résolveur DNS ou un proxy avec un bug dans la gestion du cache.
Pour "Debian APT-HTTP/1.3", c'est probablement le client apt officiel, donc je pense que c'est similaire.
Pour Apt-Cacher NG, il est peut-être possible de débloquer la situation en mettant une redirection HTTP 301 vers ubuntu.lafibre.info sur l'ancien serveur.
Ça déclencherait une nouvelle requête DNS, et avec le code actuel ça devrait vider le cache (à voir avec les anciennes versions).
Dans les autres cas, si c'est un proxy ça pourrait aider, sinon je pense qu'on ne peut rien faire.
-
Pour check_http (monitoring-plugins), le code utilise getaddrinfo, donc soit les utilisateurs ont forcé l'IP quelque part (la configuration de l'outil, /etc/hosts, ...), soit il y a un résolveur DNS ou un proxy avec un bug dans la gestion du cache.
Dans les autres cas, si c'est un proxy ça pourrait aider, sinon je pense qu'on ne peut rien faire.
Oui, parce que les résolveurs FAI répondent pas, pour diverse raisons, et au lieux d'aller pointer ailleurs, de forcer les adresses, passer à autre chose et laisser cela forcé sur des machines. Habituellement, c'est pas très grave, les machines étant mises à jours périodiquement, mais si tu modifies ton /etc/hosts pour "forcer" et bien cela reste si la machine tourne dans son coin.
C'est comme utiliser ton fichier de serveurs racines datant de mathusalem dans ton serveur de noms.
-
Je vois qu'il y a plusieurs IP qui utilisent Apt-Cacher NG (https://www.unix-ag.uni-kl.de/~bloch/acng/), pour maintenir des caches locaux (peut-être des entreprises).
Pour information, les statistiques présentées dans le tableur ne prenait pas en compte les requêtes Apt-Cacher qui étaient j’avais exclut comme tout ce qui n'est pas un user-agent Ubuntu.
C'est également le cas pour les statistiques sur le serveur de prod ( https://ubuntu.lafibre.info/stats/stats_of_day-1.html?version=last ) et à partir de demain les requêtes Apt-Cacher NG seront rajoutées dans ces stats quotidiennes.
Pour Apt-Cacher NG, il est peut-être possible de débloquer la situation en mettant une redirection HTTP 301 vers ubuntu.lafibre.com sur l'ancien serveur.
Ça déclencherait une nouvelle requête DNS, et avec le code actuel ça devrait vider le cache (à voir avec les anciennes versions).
J'ai mis en place la redirection 301 sur l'ancien serveur.
J'ai logué les requêtes 301, donc je vais voir si au-delà de 24h cela fait diminuer les requêtes sur le serveur.
-
J'ai regardé les connexion Rsync sur l'ancien serveur en filtrant sur les IP qui se connectent chaque jour sur le serveur.
Surprise : aucune AS Française et certains AS qui ont plusieurs IP, dans des plages qui sont censés être dans des pays différents :
146.70.61.x : United Kingdom AS9009 M247 LTD London
185.163.110.x : United Kingdom AS9009 M247 Europe
193.56.252.x : United Kingdom AS9009 M247 LTD Dublin
37.120.211.x : United Kingdom AS9009 M247 LTD Warsaw Infrastructure
5.253.204.x : United Kingdom AS9009 M247 Luxembourg NOC
84.39.116.x : United Kingdom AS9009 M247
84.39.117.x : United Kingdom AS9009 M247
178.238.11.x : United Kingdom AS62240 Clouvider Limited
185.169.233.x : United Kingdom AS62240 Clouvider Limited
185.169.255.x : United Kingdom AS62240 Clouvider Limited
141.98.254.x : Sweden AS39351 31173 Services Denmark
185.213.154.x : Sweden AS39351 31173 Services AB
45.129.56.x : Sweden AS39351 31173 Services Denmark
188.126.89.x : Sweden AS42708 GleSYS AB
185.204.1.x : Finland AS51765 Oy Creanova Hosting Solutions Ltd.
91.90.44.2x : Norway AS50304 Blix Solutions AS
195.200.221.x : Panama AS136787 IT MBuechele UG (haftungsbeschraenkt)
45.133.172.x : United States AS174 Cogent
-
Surprise : aucune AS Française et certains AS qui ont plusieurs IP, dans des plages qui sont censés être dans des pays différents :
Le mot le plus important c'est "censés" :D
Parce que dans les faits, pour les multinationales, j'ai vu des /8 "américaines" en Europe.
J'ai même un exemple ou après des rachats de sociétés, une multinationale avait des IP sur tous les aéroports Européens attribuées à un prestataire américain.
Aller trouver des machines mal configurées dans certains AS, t'es pas sorti de l'auberge.
-
Depuis des années, le jeux consiste à faire passer des demandes de ressources à l'AfriNIC et de les utiliser au US et en Europe.
D'ailleurs, il y a conflit juridique à ce sujet (https://www.bortzmeyer.org/afrinic-sous-attaque.html).
-
Nombre de requêtes sur le fichier "InRelease" (ex: /ubuntu/dists/focal-updates/InRelease )
21 décembre: 150 Debian APT-HTTP et 350 Debian Apt-Cacher
22 décembre: 156 Debian APT-HTTP et 340 Debian Apt-Cacher
23 décembre: 165 Debian APT-HTTP et 296 Debian Apt-Cacher
24 décembre: 148 Debian APT-HTTP et 243 Debian Apt-Cacher
25 décembre: 159 Debian APT-HTTP et 211 Debian Apt-Cacher (samedi)
26 décembre: 169 Debian APT-HTTP et 211 Debian Apt-Cacher (dimanche)
27 décembre: 164 Debian APT-HTTP et 333 Debian Apt-Cacher
28 décembre: 152 Debian APT-HTTP et 281 Debian Apt-Cacher
29 décembre: 163 Debian APT-HTTP et 251 Debian Apt-Cacher
30 décembre: 186 Debian APT-HTTP et 330 Debian Apt-Cacher
31 décembre: 160 Debian APT-HTTP et 370 Debian Apt-Cacher
01 janvier : 148 Debian APT-HTTP et 183 Debian Apt-Cacher (samedi)
02 janvier : 137 Debian APT-HTTP et 185 Debian Apt-Cacher (dimanche)
03 janvier : 137 Debian APT-HTTP et 322 Debian Apt-Cacher
04 janvier : 154 Debian APT-HTTP et 335 Debian Apt-Cacher
05 janvier : 155 Debian APT-HTTP et 384 Debian Apt-Cacher
06 janvier : 141 Debian APT-HTTP et 376 Debian Apt-Cacher
07 janvier : 135 Debian APT-HTTP et 347 Debian Apt-Cacher
08 janvier : 125 Debian APT-HTTP et 197 Debian Apt-Cacher (samedi)
09 janvier : 128 Debian APT-HTTP et 187 Debian Apt-Cacher (dimanche)
10 janvier : 136 Debian APT-HTTP et 403 Debian Apt-Cacher
11 janvier : 137 Debian APT-HTTP et 372 Debian Apt-Cacher
12 janvier : 140 Debian APT-HTTP et 298 Debian Apt-Cacher
13 janvier : 145 Debian APT-HTTP et 313 Debian Apt-Cacher
14 janvier : 149 Debian APT-HTTP et 259 Debian Apt-Cacher
15 janvier : 118 Debian APT-HTTP et 186 Debian Apt-Cacher (samedi)
16 janvier : 126 Debian APT-HTTP et 176 Debian Apt-Cacher (dimanche)
17 janvier : 139 Debian APT-HTTP et 390 Debian Apt-Cacher
18 janvier : 133 Debian APT-HTTP et 331 Debian Apt-Cacher
19 janvier : 134 Debian APT-HTTP et 253 Debian Apt-Cacher
20 janvier : 132 Debian APT-HTTP et 383 Debian Apt-Cacher
21 janvier : 137 Debian APT-HTTP et 225 Debian Apt-Cacher
22 janvier : 115 Debian APT-HTTP et 166 Debian Apt-Cacher (samedi)
23 janvier : 129 Debian APT-HTTP et 166 Debian Apt-Cacher (dimanche)
24 janvier : 142 Debian APT-HTTP et 353 Debian Apt-Cacher
25 janvier : 128 Debian APT-HTTP et 288 Debian Apt-Cacher
26 janvier : 132 Debian APT-HTTP et 257 Debian Apt-Cacher
27 janvier : 146 Debian APT-HTTP et 285 Debian Apt-Cacher
28 janvier : 129 Debian APT-HTTP et 340 Debian Apt-Cacher
29 janvier : 123 Debian APT-HTTP et 200 Debian Apt-Cacher (samedi)
30 janvier : 116 Debian APT-HTTP et 162 Debian Apt-Cacher (dimanche)
31 janvier : 131 Debian APT-HTTP et 256 Debian Apt-Cacher
01 février : 124 Debian APT-HTTP et 248 Debian Apt-Cacher
02 février : 135 Debian APT-HTTP et 427 Debian Apt-Cacher
03 février : 131 Debian APT-HTTP et 498 Debian Apt-Cacher
Je note que la redirection 301 mise en place le 27 janvier n'a pas eu d'incidence : les flux n'ont pas baissés.
On voit qu'il y a bien plus de requêtes "Debian Apt-Cacher" que "Debian APT-HTTP".
Autre point intéressant, les requêtes "Debian Apt-Cacher" baissent le week-end (ce n'est pas le cas de "Debian APT-HTTP").
-
Autre point intéressant, les requêtes "Debian Apt-Cacher" baissent le week-end (ce n'est pas le cas de "Debian APT-HTTP").[/size]
Il doit s'agir de caches sur des réseaux d'entreprises, utilisés pour diminuer le trafic généré par les PC qui vont tous télécharger les mêmes mises à jour.
-
Je vois qu'il y a plusieurs IP qui utilisent Apt-Cacher NG (https://www.unix-ag.uni-kl.de/~bloch/acng/), pour maintenir des caches locaux (peut-être des entreprises).
Le code change beaucoup en fonction des versions, je n'ai pas regardé pour celles utilisées ici.
Sur les versions les plus récentes, j'ai l'impression qu'il y a un bug dans le cache.
Au moment de faire la requête, le code ne vérifie pas l'expiration de son cache DNS.
Ça rappelle le code naïf de ntpd qui –dans d'anciennes versions– ne résolvait les FQDN qu'une fois pour toutes au lancement du service ::)
ça pourrait pas être des dnsmasq, pihole, ou autre programme de cache DNS en version obsolète ou buggé ou mal configuré, qui pourrait toujours répondre la même IP ?
Il y a une dizaine d'années j'ai ainsi dégagé PowerDNS Recursor dont le cache était buggé à mort avec certains enregistrements qui devenaient éternels (et c'était pas sur de la box clients).
Ceci étant dit il suffit de lire les release notes des récurseurs habituels du marché pour voir que les caches qui déconnent, ça arrive de temps en temps chez tout le monde.