Auteur Sujet: DNS: Pourquoi certains PC continuent de faire des requêtes sur les anciennes IP? (Lu 5078 fois)

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

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)

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.

vivien · « **Réponse #1 le:** 23 janvier 2022 à 22:53:58 »

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 :

eupalynos · « **Réponse #2 le:** 24 janvier 2022 à 00:58:24 »

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+

Anonyme · « **Réponse #3 le:** 24 janvier 2022 à 01:25:31 »

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:

Code: [Sélectionner]

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:
>

Code: [Sélectionner]

> 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):

Code: [Sélectionner]

> 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 :

Code: [Sélectionner]

** 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
>

vivien · « **Réponse #4 le:** 24 janvier 2022 à 09:00:11 »

Citation de: eupalynos le 24 janvier 2022 à 00:58:24

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.

Citation de: Anonyme le 24 janvier 2022 à 01:25:31

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.

Code: [Sélectionner]

$ 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.

Anonyme · « **Réponse #5 le:** 24 janvier 2022 à 10:26:09 »

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.

Fuli10 · « **Réponse #6 le:** 25 janvier 2022 à 15:20:19 »

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.

kazyor · « **Réponse #7 le:** 25 janvier 2022 à 15:50:11 »

@vivien, quel était l'ancienne adresse IP ?

vivien · « **Réponse #8 le:** 25 janvier 2022 à 17:55:18 »

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

kazyor · « **Réponse #9 le:** 25 janvier 2022 à 18:55:28 »

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 ?

eupalynos · « **Réponse #10 le:** 25 janvier 2022 à 21:02:22 »

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...

vivien · « **Réponse #11 le:** 26 janvier 2022 à 09:55:46 »

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) :

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.