échec de résolution DNS sur google

8 réponses
Avatar
Benoit
Bonjour,

Sur un XP qui a été équipé d'un Avast gratuit & d'un Norton 360 en même
temps.

La résolution dns (avec nslookup) sur les domaines google.fr, google.com
google-analytics.com échoue. Pas de réponse, time-out. Une autre machine sur
le même réseau (utilisant la même box) n'a pas ce problème. Le problème
persiste au changement des serveurs dns (initialement donnés par la box
DHCP).

Ce problème persiste après désinstallation des anti-virus. Un seul a été
remis en service (avast).

Pour pallier ce problème le fichier hosts a été utilisé avec les ips des
domaines concernés.

Il est possible qu'il reste un résidu d'une éventuelle (voire certaine)
cochonnerie ou d'une bataille rangée entre Norton et Avast pour le contrôle
de la machine.

D'où la question : à quel endroit faudrait-il placer ce genre de chose pour
empêcher la résolution dns d'un domaine particulier ?

Merci pour vos avis éclairés.
--
Pourquoi faire simple quand on peut faire compliqué ?
Kiss.

8 réponses

Avatar
willpot
Ni aurait-il pas un directory, fichier, virus "Plus-HD-4.9" ou équivalent ?
J' ai eu un Pb en allant sur les sites ASUS ou ATI Radeon


"Benoit" a écrit dans le message de news:
52e7e2b6$0$2272$
Bonjour,

Sur un XP qui a été équipé d'un Avast gratuit & d'un Norton 360 en même
temps.

La résolution dns (avec nslookup) sur les domaines google.fr, google.com
google-analytics.com échoue. Pas de réponse, time-out. Une autre machine
sur le même réseau (utilisant la même box) n'a pas ce problème. Le
problème persiste au changement des serveurs dns (initialement donnés par
la box DHCP).

Ce problème persiste après désinstallation des anti-virus. Un seul a été
remis en service (avast).

Pour pallier ce problème le fichier hosts a été utilisé avec les ips des
domaines concernés.

Il est possible qu'il reste un résidu d'une éventuelle (voire certaine)
cochonnerie ou d'une bataille rangée entre Norton et Avast pour le
contrôle de la machine.

D'où la question : à quel endroit faudrait-il placer ce genre de chose
pour empêcher la résolution dns d'un domaine particulier ?

Merci pour vos avis éclairés.
--
Pourquoi faire simple quand on peut faire compliqué ?
Kiss.







---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
Avatar
Sergio
Le 28/01/2014 18:02, Benoit a écrit :

Sur un XP qui a été équipé d'un Avast gratuit & d'un Norton 360 en même
temps.

La résolution dns (avec nslookup) sur les domaines google.fr, google.com
google-analytics.com échoue. Pas de réponse, time-out. Une autre machine sur
le même réseau (utilisant la même box) n'a pas ce problème. Le problème
persiste au changement des serveurs dns (initialement donnés par la box
DHCP).

Il est possible qu'il reste un résidu d'une éventuelle (voire certaine)
cochonnerie ou d'une bataille rangée entre Norton et Avast pour le contrôle
de la machine.

D'où la question : à quel endroit faudrait-il placer ce genre de chose pour
empêcher la résolution dns d'un domaine particulier ?



Il faut restaurer le fichier hosts

Sous XP, il est là :
%WinDir%system32driversetc

Il doit contenir :
-------------------

# Copyright (c) 1993-2006 Microsoft Corp. # # Il s'agit d'un exemple de fichier hôtes utilisé par Microsoft TCP/IP pour Windows. # #
Ce fichier contient les mappages d'adresses IP aux noms d'hôte. Chaque
# entrée doit être maintenue sur une ligne individuelle. L'adresse IP doit
# être placée dans la première colonne et suivie du nom d'hôte correspondant.
# L'adresse IP et le nom d'hôte doivent être séparés par au moins un
# espace.
#
# En outre, des commentaires (tels que ceux-ci) peuvent être insérés sur des lignes
# individuelles ou derrière le nom de la machine désigné par un symbole « # ».
#
# Par exemple :
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost ::1 localhost
--------------------------

(en gros, seule la dernière ligne est importante)

cf: http://support.microsoft.com/kb/972034/fr

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Avatar
houba
Bonjour ° Bonsoir, le Tue, 28 Jan 2014 18:02:35 +0100, "Benoit"
a wroté:

Bonjour,


salut,

Sur un XP qui a été équipé d'un Avast gratuit & d'un Norton 360 en même
temps.

La résolution dns (avec nslookup) sur les domaines google.fr, google.com
google-analytics.com échoue. Pas de réponse, time-out. Une autre machine sur
le même réseau (utilisant la même box) n'a pas ce problème. Le problème
persiste au changement des serveurs dns (initialement donnés par la box
DHCP).



soit:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:Documents and Settingsuser>nslookup
Default Server: dns1.proxad.net
Address: 212.27.40.240

www.google.com


Server: dns1.proxad.net
Address: 212.27.40.240

Non-authoritative answer:
Name: www.google.com
Addresses: 173.194.78.103, 173.194.78.104, 173.194.78.105,
173.194.78.147, 173.194.78.99, 173.194.78.106

exit



C:Documents and Settingsuser>ping 173.194.78.103

Pinging 173.194.78.103 with 32 bytes of data:

Reply from 173.194.78.103: bytes2 TTLC
Reply from 173.194.78.103: bytes2 time)ms TTLC
Reply from 173.194.78.103: bytes2 time0ms TTLC
Reply from 173.194.78.103: bytes2 time0ms TTLC

Ping statistics for 173.194.78.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 40ms, Average = 32ms

C:Documents and Settingsuser>

C'est curieux que cela ne t'arrive que pour _Google_. Je sais qu'il y
a 4-5jours?, le 25/01, les serveurs de Google avaient des pbs. On ne
pouvait envoyer du courriel par gmail.
Mais si c'est généralisé, alors une destruction de la connexion
s'imposerait. Tu redémarres et tu as une nouvelle connexion toute
propre. Reste à renseigner tous les champs (ip, passerelle, ....dns du
FAI), pour dépanner sur un réseau c'est plus commode de fixer les IP
en dur.

Mais si tu as du temps libre et que tu cherches à comprendre le
pourquoi du comment.
http://support.microsoft.com/kb/914440/fr
http://technet.microsoft.com/fr-fr/library/cc757819(v=ws.10).aspx

Ce problème persiste après désinstallation des anti-virus. Un seul a été
remis en service (avast).


Ouf, très mauvais d'avoir 2 AV _actifs_ simultanément.

Pour pallier ce problème le fichier hosts a été utilisé avec les ips des
domaines concernés.


arf ;), je ne l'utilise que pour condamner l'accès à diff. domaines.
http://winhelp2002.mvps.org/hosts.htm

Il est possible qu'il reste un résidu d'une éventuelle (voire certaine)
cochonnerie ou d'une bataille rangée entre Norton et Avast pour le contrôle
de la machine.


Par ex., mais aussi des MàJ beuguées.

D'où la question : à quel endroit faudrait-il placer ce genre de chose pour
empêcher la résolution dns d'un domaine particulier ?

Merci pour vos avis éclairés.


Ce n'est qu'un simple avis pour ma part.

--
VaN.
Avatar
Sergio
Le 29/01/2014 11:18, houba a écrit :

C'est curieux que cela ne t'arrive que pour _Google_. Je sais qu'il y



Pas bizarre du tout : Un "pubware" (pour ne pas dire une saloperie) qui détourne les requêtes vers Google pour envoyer vers son
propre moteur de recherche favorisant ses annonceurs et éliminant toute allusion à sa suppression.

Cette saloperie a été éliminé, mais mal, par un des antivirus...

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Avatar
Benoit
"Sergio" a écrit dans le message de news:
52e8fbea$0$2075$
Le 29/01/2014 11:18, houba a écrit :

C'est curieux que cela ne t'arrive que pour _Google_. Je sais qu'il y



Pas bizarre du tout : Un "pubware" (pour ne pas dire une saloperie) qui
détourne les requêtes vers Google pour envoyer vers son propre moteur de
recherche favorisant ses annonceurs et éliminant toute allusion à sa
suppression.



C'est au final ce que je pense

Cette saloperie a été éliminé, mais mal, par un des antivirus...


+1

J'ai oublié de mentionner quelque-chose d'hyper important. Pour que le
Windows puisse retrouver *google* j'ai donc modifié le fichier hosts en y
insérant les bonnes adresse ip et donc tout est rentré dans un certain
ordre. Par contre j'ai trouvé un fichier hosts avec les attributs SHR
d'activés, histoire qu'on ne puisse pas le trouver depuis l'explorateur et
encore moins le modifier...

Je vais commencer par voir autour du nslookup.exe et de ses dépendances si
tout va bien et le remplacer avec l'original.

à plus tard, donc.

--
Benoit
Pourquoi faire simple quand on peut faire compliqué ?
Kiss :P
Avatar
houba
Bonjour ° Bonsoir, le Wed, 29 Jan 2014 14:02:34 +0100, Sergio
a wroté:

Le 29/01/2014 11:18, houba a écrit :

C'est curieux que cela ne t'arrive que pour _Google_. Je sais qu'il y



Pas bizarre du tout : Un "pubware" (pour ne pas dire une saloperie) qui détourne les requêtes vers Google pour envoyer vers son
propre moteur de recherche favorisant ses annonceurs et éliminant toute allusion à sa suppression.

Cette saloperie a été éliminé, mais mal, par un des antivirus...


J'ai surement mal compris mais le genre de pubW (PuP?) dont tu parles
affiche direct une page de pub, la même ou différente à chaque fois,
dès que tu cliques sur un des liens de recherche proposé par Google ou
que tu valides un lien dans la barre d'adresse (diiférents
comportements possibles).
Dans le cas qui nous concerne, le PO n'arrive _même pas_ à atteindre
Google.

Mais peut être aurais-tu un exemple concret de pupW qui détournerait
_vers_ Google (au lieu d'aller directement sur leurs propres sites
portails ou le site où ils étaient programmés pour rapatrier), pour
atteindre son propre moteur de recherche, afin de rapatrier leurs
annonceurs / fournisseurs ?

Enfin selon toi? et toujours dans le cas qui nous concerne, il y
aurait donc un/plusieurs pupW qui auraient tellement inondé Google,
qu'1 des 2 ou les 2 AV interdiraient dorénavant l'accès à Google en
modifiant le 'Hosts' ?
Est ce que cela résumerait un peu ton idée ?
Perso, je n'ai pas encore vu d'AV qui modifierait le 'Hosts' pour
rejeter l'accès à certains domaines. Mébon on en apprend tous les
jours....

Mais dans ce cas, pourquoi lui aurais-tu proposé de remettre son
'Hosts' par défaut alors que le PO disait lui- même: "Pour pallier ce
problème le fichier hosts a été utilisé avec les ips des domaines
concernés.".
Ce qui, pour moi, le PO a autorisé et déclaré en clair les ip et les
noms de domaines idoines. Crois tu qu'il ne serait _pas apercu_ que
les domaines Google en question ont été rejetés par un début de ligne
en "127.0.0.1" ou "0.0.0.0"?

--
VaN.
Avatar
Benoit
"Benoit" a écrit dans le message de news:
52e909ea$0$2213$

"Sergio" a écrit dans le message de news:
52e8fbea$0$2075$
Le 29/01/2014 11:18, houba a écrit :

C'est curieux que cela ne t'arrive que pour _Google_. Je sais qu'il y



Pas bizarre du tout : Un "pubware" (pour ne pas dire une saloperie) qui
détourne les requêtes vers Google pour envoyer vers son propre moteur de
recherche favorisant ses annonceurs et éliminant toute allusion à sa
suppression.



C'est au final ce que je pense

Cette saloperie a été éliminé, mais mal, par un des antivirus...


+1

J'ai oublié de mentionner quelque-chose d'hyper important. Pour que le
Windows puisse retrouver *google* j'ai donc modifié le fichier hosts en y
insérant les bonnes adresse ip et donc tout est rentré dans un certain
ordre. Par contre j'ai trouvé un fichier hosts avec les attributs SHR
d'activés, histoire qu'on ne puisse pas le trouver depuis l'explorateur et
encore moins le modifier...

Je vais commencer par voir autour du nslookup.exe et de ses dépendances si
tout va bien et le remplacer avec l'original.



Donc alors, renommé nslookup.exe et dnsapi.dll, évidemment XP s'empresse de
regénerer les fichiers manquants. résolution dns toujours bloquée pour
google.

Attention la suite est très intéressante... j'installe le moniteur réseau
pour capturer les paquets, et les requètes dns partent bien en udp et la
réponse arrive bien en query refused !
De plus en plus fort, je change l'adresse du serveur de résolution dns dans
la session nslookup en la faisant pointer sur mon serveur dns perso "at
home". Sur le serveur concerné, je démarre un tcpdump du traffic udp. Je
commence par interroger les domains gérés par le serveur. La réponse est ok
et le traffic est bien affiché. Je demande ensuite un google.fr ou
google.com, et hop réponse immédiate *query refused* mais rien coté traffic
udp. La demande udp n'a donc pas quitté le PC et a été interceptée.
Encore plus fort : demande de résolution sur google-analytics.com et là,
réponse unique : 92.123.68.97, il s'agit d'une ip sur le réseau AKAMAI. Mais
ça n'a rien à voir avec une réponse normale qui donne des adresses en
173.194.67.*

J'ai donc bien une sorte de cochenerie qui intercepte le traffic de
résolution dns. je transfère donc tout cela au bon endroit.

Il ne me reste plus qu'à trouver l'intercepteur. Merci pour vos idées à ce
sujet.
--
Benoit
Pourquoi faire simple quand on peut faire compliqué ?
Kiss :P
Avatar
Benoit
"Benoit" a écrit dans le message de news:
52e965fe$0$2227$
"Benoit" a écrit dans le message de news:
52e909ea$0$2213$

"Sergio" a écrit dans le message de news:
52e8fbea$0$2075$
Le 29/01/2014 11:18, houba a écrit :

C'est curieux que cela ne t'arrive que pour _Google_. Je sais qu'il y



Pas bizarre du tout : Un "pubware" (pour ne pas dire une saloperie) qui
détourne les requêtes vers Google pour envoyer vers son propre moteur de
recherche favorisant ses annonceurs et éliminant toute allusion à sa
suppression.



C'est au final ce que je pense

Cette saloperie a été éliminé, mais mal, par un des antivirus...


+1

J'ai oublié de mentionner quelque-chose d'hyper important. Pour que le
Windows puisse retrouver *google* j'ai donc modifié le fichier hosts en y
insérant les bonnes adresse ip et donc tout est rentré dans un certain
ordre. Par contre j'ai trouvé un fichier hosts avec les attributs SHR
d'activés, histoire qu'on ne puisse pas le trouver depuis l'explorateur
et encore moins le modifier...

Je vais commencer par voir autour du nslookup.exe et de ses dépendances
si tout va bien et le remplacer avec l'original.



Donc alors, renommé nslookup.exe et dnsapi.dll, évidemment XP s'empresse
de regénerer les fichiers manquants. résolution dns toujours bloquée pour
google.

Attention la suite est très intéressante... j'installe le moniteur réseau
pour capturer les paquets, et les requètes dns partent bien en udp et la
réponse arrive bien en query refused !
De plus en plus fort, je change l'adresse du serveur de résolution dns
dans la session nslookup en la faisant pointer sur mon serveur dns perso
"at home". Sur le serveur concerné, je démarre un tcpdump du traffic udp.
Je commence par interroger les domains gérés par le serveur. La réponse
est ok et le traffic est bien affiché. Je demande ensuite un google.fr ou
google.com, et hop réponse immédiate *query refused* mais rien coté
traffic udp. La demande udp n'a donc pas quitté le PC et a été
interceptée.
Encore plus fort : demande de résolution sur google-analytics.com et là,
réponse unique : 92.123.68.97, il s'agit d'une ip sur le réseau AKAMAI.
Mais ça n'a rien à voir avec une réponse normale qui donne des adresses en
173.194.67.*

J'ai donc bien une sorte de cochenerie qui intercepte le traffic de
résolution dns. je transfère donc tout cela au bon endroit.

Il ne me reste plus qu'à trouver l'intercepteur. Merci pour vos idées à ce
sujet.



Allez zou, résidu de Win32:RLoader-B - En cours de nettoyache.

--
Benoit
Pourquoi faire simple quand on peut faire compliqué ?
Kiss :P