Auteur Sujet: DNS menteurs chez Bouygues Telecom mobile (Lu 7973 fois)

« **le:** 24 juillet 2017 à 13:06:25 »

DNS menteurs chez Bouygues Telecom mobile

Je cherche à comprendre pourquoi le site ZD Net (http://www.zdnet.fr/) ne fonctionne pas sur un PC en partage de connexion avec la 4G Bouygues (alors que cela fonctionne très bien directement sur le mobile)

La réponse est simple : le serveur répond [RST] a mes [ACK]

Je m’aperçois d'une chose : Le DNS ne me renvoi pas vers l'IP habituelle de ZD net :

Code: [Sélectionner]

$ dig www.zdnet.fr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50268
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.zdnet.fr.			IN	A

;; ANSWER SECTION:
www.zdnet.fr.		7021	IN	CNAME	wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 268 IN A 212.195.244.75

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jul 24 12:54:33 CEST 2017
;; MSG SIZE  rcvd: 110

La capture Wireshark :

« **Réponse #1 le:** 24 juillet 2017 à 13:13:22 »

Encore plus fort : Cela fonctionne en modifiant le TTL !

Le DNS ne donne pas la même IP si le TTL est paire ou impaire !

Code: [Sélectionner]

$ dig www.zdnet.fr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51064
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.zdnet.fr.			IN	A

;; ANSWER SECTION:
www.zdnet.fr.		5977	IN	CNAME	wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 118 IN A 62.34.202.116

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Jul 24 13:11:57 CEST 2017
;; MSG SIZE  rcvd: 110

Tutoriel pour modifier le TTL :

Citation de: benoit75015 le 09 août 2016 à 13:45:52

Bouygues Telecom décompte la consommation du forfait, en présence d'un routeur/partage de connexion coté abonné sur son bonus option illimité le week-end.

Pour avoir le trafic en illimité, même en mode modem (ou avec un routeur 4G) il faut modifier le TTL des PC connecté à ton point d’accès pour avoir l'illimité même sur PC :
- TTL = 63 ou 64 ou 127 ou 128 = facturation (par défaut le TTL est de 64 ou 128)
- TTL autre que 63 ou 64 ou 127 ou 128 = non facturation (enfin je n'ai testé qu'avec un TTL de 65)

Modifier le TTL sur Windows

Commande pour afficher le TTL sous Windows :
netsh int ipv4 show glob
netsh int ipv6 show glob

Changement du TTL sous Windows pour avoir de la data illimitée : (à exécuter avec les privilèges administrateurs)
netsh int ipv4 set glob defaultcurhoplimit=65
netsh int ipv6 set glob defaultcurhoplimit=65

Modifier le TTL sur Linux :

Commande pour afficher le TTL sous Linux :
cat /proc/sys/net/ipv4/ip_default_ttl
64

Commande pour changer le TTL sous Linux pour avoir de la data illimitée :
sudo sysctl net.ipv4.ip_default_ttl=65

Commande pour rendre le changement de TTL persistant au redémarrage sous Linux :
sudo nano /etc/sysctl.conf

Rajouter en début de fichier la ligne :
net.ipv4.ip_default_ttl = 65

Exemple :

Modifier le TTL sur MacOS

Commande pour changer le TTL sous MacOS pour avoir de la data illimitée :
sudo sysctl -w net.inet.ip.ttl=65

Modifier le TTL sur un routeur

Pour les routeurs basés sur Linux, qui permettent de rajouter une ligne iptables, voici la ligne à rajouter pour forcer un TTL de 65 pour tous les périphériques :

iptables -t mangle -I POSTROUTING -o `nvram get wan_iface` -j TTL --ttl-set 65

« **Réponse #2 le:** 24 juillet 2017 à 17:23:40 »

J'ai réalisé de nombreux tests.

Les IP récupérées par le DNS avec TTL de 65 et 64 (62.34.202.116 et 212.195.244.75) ont toutes les deux le même comportement

Mon PC Ubuntu es connecté à mon téléphone en mode modem
- En configurant un TTL de 6 à 62, le site répond bien.
- TTL 63 => non ok
- TTL 64 => non ok
- En configurant un TTL de 65 à 126, le site répond bien.
- TTL 127 non ok
- TTL 128 non ok
- En configurant un TTL de 129 à 255, le site répond bien.

TTL de 62 : le serveur répond

Code: [Sélectionner]

$ sudo sysctl net.ipv4.ip_default_ttl=62
net.ipv4.ip_default_ttl = 62
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
Connected to 62.34.202.116.
Escape character is '^]'.
ok
HTTP/1.1 501 Not Implemented
Content-type: text/html
Content-Length: 219

<HTML><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"></head><center>Erreur 501<br>M&eacute;thode non support&eacute;e</center><hr>Le serveur HTTP ne peut pas traiter votre requ&ecirc;te.</HTML>
Connection closed by foreign host.

TTL de 63 : Le serveur ne répond pas

Code: [Sélectionner]

$ sudo sysctl net.ipv4.ip_default_ttl=63
net.ipv4.ip_default_ttl = 63
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
telnet: Unable to connect to remote host: Connection refused

TTL de 64 : Le serveur ne répond pas

Code: [Sélectionner]

$ sudo sysctl net.ipv4.ip_default_ttl=64
net.ipv4.ip_default_ttl = 64
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
telnet: Unable to connect to remote host: Connection refused

TTL de 65 : Le serveur répond

Code: [Sélectionner]

$ sudo sysctl net.ipv4.ip_default_ttl=65
net.ipv4.ip_default_ttl = 65
$ telnet 62.34.202.116 80
Trying 62.34.202.116...
Connected to 62.34.202.116.
Escape character is '^]'.
ok
HTTP/1.1 501 Not Implemented
Content-type: text/html
Content-Length: 219

<HTML><head><meta http-equiv="Content-Type" content="text/html;charset=utf-8"></head><center>Erreur 501<br>M&eacute;thode non support&eacute;e</center><hr>Le serveur HTTP ne peut pas traiter votre requ&ecirc;te.</HTML>
Connection closed by foreign host.

Le même comportement est observé que ce soit 62.34.202.116 ou 212.195.244.75.

MystR30 · « **Réponse #3 le:** 24 juillet 2017 à 17:28:26 »

J'ai remarqué ce problème également ce matin sans aller toutefois chercher du côté des DNS

vivien · « **Réponse #4 le:** 25 juillet 2017 à 07:57:26 »

La bonne entrée DNS a utiliser est 146.185.42.33

C'est hébergé par AS47841 Oxalide (https://www.oxalide.com/)

Code: [Sélectionner]

$ dig www.zdnet.fr

; <<>> DiG 9.9.5-3ubuntu0.15-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.zdnet.fr.			IN	A

;; ANSWER SECTION:
www.zdnet.fr.		900	IN	A	146.185.42.33

;; AUTHORITY SECTION:
zdnet.fr.		900	IN	NS	ns10.cbsig.net.
zdnet.fr.		900	IN	NS	ns11.cbsig.net.

;; ADDITIONAL SECTION:
ns10.cbsig.net.		4697	IN	A	62.108.128.10
ns11.cbsig.net.		4697	IN	A	62.108.129.11

;; Query time: 113 msec
;; SERVER: 91.194.96.11#53(91.194.96.11)
;; WHEN: Tue Jul 25 07:54:44 CEST 2017
;; MSG SIZE  rcvd: 136

« **Réponse #5 le:** 26 juillet 2017 à 08:16:27 »

J'ai recherché l'objectif poursuivit par Bouygues Telecom en forçant le passage par wpxy-proxyless.wip-ext.bouyguestelecom.fr

J'ai vérifié sur la page d’accueil : le contenu n'est pas modifié.

Bref, j'ai du mal à saisir ce qui a motivé un mensonge sur les DNS.

« **Réponse #6 le:** 03 août 2017 à 11:18:00 »

Le blocage de ZD Net n'est toujours pas levé.

Autre nom de domaine qui pose problème : authentication.0pb.org (il est nécessaire pour certains sites web, comme par exemple KKO Store) => On est redirigé sur la même IP que ZD Net et l’accès est impossible sans changer son TTL :

Code: [Sélectionner]

$ dig authentication.0pb.org

; <<>> DiG 9.10.3-P4-Ubuntu <<>> authentication.0pb.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 838
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;authentication.0pb.org.		IN	A

;; ANSWER SECTION:
authentication.0pb.org.	7006	IN	CNAME	wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 47 IN A 62.34.202.116

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Aug 03 11:12:04 CEST 2017
;; MSG SIZE  rcvd: 122

Boris de Bouygues Telecom · « **Réponse #7 le:** 23 août 2017 à 14:16:15 »

Le problème a été remonté en interne.

Merci pour vos retours.

Cordialement,
Boris de Bouygues Telecom.

Boris de Bouygues Telecom · « **Réponse #8 le:** 19 septembre 2017 à 10:45:11 »

L’accès à ZD-Net a été rétabli pour le mode modem.

Cordialement,
Boris de Bouygues Telecom.

« **Réponse #9 le:** 05 octobre 2017 à 09:18:23 »

Le site ZD-Net fonctionne, mais l'IP récupérée par le DNS n'est toujours pas la bonne :

Code: [Sélectionner]

$ dig www.zdnet.fr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.zdnet.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42883
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.zdnet.fr.			IN	A

;; ANSWER SECTION:
www.zdnet.fr.		7051	IN	CNAME	wpxy-proxyless.wip-ext.bouyguestelecom.fr.
wpxy-proxyless.wip-ext.bouyguestelecom.fr. 36 IN A 212.195.244.75

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Oct 05 09:15:57 CEST 2017
;; MSG SIZE  rcvd: 110

Boris de Bouygues Telecom · « **Réponse #10 le:** 05 octobre 2017 à 10:56:25 »

Bonjour,

La réponse DNS de www.zdnet.fr est en accord avec l'éditeur de ZD-Net.

Je ne pense pas pouvoir expliquer la raison ici, sans leur accord.
Si vous les contactez, ils vous expliqueront peut-être.

miky01 · « **Réponse #11 le:** 05 octobre 2017 à 15:03:30 »

Citation de: Boris de Bouygues Telecom le 05 octobre 2017 à 10:56:25

Bonjour,

La réponse DNS de www.zdnet.fr est en accord avec l'éditeur de ZD-Net.

Je ne pense pas pouvoir expliquer la raison ici, sans leur accord.
Si vous les contactez, ils vous expliqueront peut-être.

Ta réponse veux dire que un éditeur peux demander a un FAI de retourner sur son DNS une adresse qui est pas celle officiellement déclarée ? Car la c'est bien le DNS de BT qui donne une réponse erronée.

Un fouisseur de services DNS peux légalement faire pointer une IP n'importe quoi légalement ?

Si je teste avec mes 3 connections et les DNS par défaut assignés par DHCP, K-Net FTTH, Orange ADSL, BT 4G, voila les résultats.