je confirme que c’est pareil sous gentoo
pareil: sur mes vieilles sarge pas de resolution avec lynx; mais host résoud pourtant bien partout.
@belga: en fait je m’adressais à fran.b puisqu’il est le seul chez qui cela fonctionne, il devait bien avoir une différence par rapport à nous tous … désolé j’avais oublié le “@”. 
(d’ailleurs il était sous linux puisque sous sarge comme le test de mattotop)
Pour répondre à ta question, un routeur sous Linux c’est simplement un linux paramétré comme ton routeur “boite” avec le wifi mais en beaucoup plus puissant et surtout réellement paramétrable.
@mattotop: si host résoud bien alors cela élimine la possibilité d’un bug dans une librairie partagée puisque host et dig utilisent exactement les mêmes.
[quote=“helid”]@belga: en fait je m’adressais à fran.b puisqu’il est le seul chez qui cela fonctionne, il devait bien avoir une différence par rapport à nous tous … désolé j’avais oublié le “@”. (d’ailleurs il était sous linux puisque sous sarge comme le test de mattotop)
Pour répondre à ta question, un routeur sous Linux c’est simplement un linux paramétré comme ton routeur “boite” avec le wifi mais en beaucoup plus puissant et surtout réellement paramétrable.
@mattotop: si host résoud bien alors cela élimine la possibilité d’un bug dans une librairie partagée puisque host et dig utilisent exactement les mêmes.[/quote]
La différence c’est que j’ai essayé sur un Firefox sur une debian sarge. Avec iceweasel sur Etch, ça coince effectivement
Merci fran.b, c’est pas la première différence entre ces deux logiciels que je vois (le greffon “Server Spy” ne fonctionne pas sous iceweasel, entre autres). 
Si quelqu’un a Opera qui fonctionne cela permettrait de faire un complément de test. Je parie qu’il va fonctionner lui aussi.
Resteras à trouver le coupable sous Linux qui ne le fait pas ! 
Sous Ubuntu Feisty:
_Opera: V.9.21 = negatif
_Firefox V.2.0.0.4= negatif
_Epiphany V.2.18.1= negatif
_Konqueror V.3.5.6 = negatif
Effacé.
Bon, je peaufine: En fait ça n’est pas un pbm d’iceweasel, firefox ou non. Si je passe par un proxy en mode non transparent (squid 2.5.9-10 sur une sarge), ça ne pose aucun problème. Par contre, en utilisant le même squid en mode transparent (y compris juste après un accès sans souci), sur le même navigateur et la même machine donne une erreur:
Il faut donc regarder ce qui fait la différence entre un accès Squid transparent et un accès normal.
MAIS si je lance qemu avec XP dessus et un internet explorer, le site fonctionne (sur le même Squid en accès transparent) … Je suis vraiment perplexe: résumé
Même machine,
- proxy en mode transparent: Pas d’accès sur un linux, accès sur un XP y compris un XP sous qemu (qui utilise donc qemu comme DNS…)
- proxy en accès normal: Accès sous linux, XP, …
En me positionant sur mon routeur (gentoo) donc sans proxy local, j’ai le même problême sous linux.
Mais j’ai vérifié sur mon LAN au boulot, les machines linux passant par mon squid en direct en contournant la transparence posent toujours problême, contrairement à ce que tu dis: le problême existe sous linux en proxy non transparent chez moi.
Qu’est ce que c’est ececi ?
je pense que tu es déjà passé par un proxy en precisant une adresse ip et un port, et bien rendre transparent le proxy, c’est rediriger (par exemple pour le http) ce qui va vers le port 80 du lan vers le port du proxy sans que les clients sachent qu’ils passent par un proxy et sans qu’ils naient besoin de configurer quoi que ce soit.
Avec un faux identifiant de navigateur (Opera sous XP) -> 502.
Avec Lynx 1) via l’IP -> je tombe sur deviantart.com, 2) via l’adresse -> 502.
Avec links2 -> “host not found”.
En accès direct, donc sans proxy -> “site introuvable” sous iceweasel.
Là c’est pas une librairie partagée en tout cas:
[quote]$ traceroute -F -l -v -w 10 gui_.deviantart.com
traceroute: unknown host gui_.deviantart.com
$ ldd which traceroute
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7dc5000)
/lib/ld-linux.so.2 (0x80000000)[/quote]
Édit: merci mattotop, je viens de tout corriger.
je corrige parceque tu n’avais pas pris le bon URL, et j’ajoute que c’est pareil sur 64 bits:roc@roc:~/vdo$ traceroute -F -l -v -w 10 gui-.deviantart.com
traceroute: unknown host gui-.deviantart.com
roc@roc:~/vdo$ ldd `which traceroute`
libc.so.6 => /lib/libc.so.6 (0x00002ae1c5ff7000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
Merci mattotop ta correction m’a permis de mieux voir:
[quote]$ dig gui-.deviantart.com
; <<>> DiG 9.4.1 <<>> gui-.deviantart.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8316
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;gui-.deviantart.com. IN A
;; ANSWER SECTION:
gui-.deviantart.com. 600 IN A 198.172.81.21
;; AUTHORITY SECTION:
deviantart.com. 155993 IN NS a.ns.deviantart.com.
deviantart.com. 155993 IN NS b.ns.deviantart.com.
deviantart.com. 155993 IN NS c.ns.deviantart.com.
;; ADDITIONAL SECTION:
a.ns.deviantart.com. 32224 IN A 69.28.181.34
b.ns.deviantart.com. 117393 IN A 66.28.104.5
c.ns.deviantart.com. 155993 IN A 69.28.181.34
;; Query time: 204 msec
;; SERVER: xxx…
;; WHEN: Sun Jun 24 12:24:46 2007
;; MSG SIZE rcvd: 152
[/quote]
Donc oui, avec l’ip j’arrive sur devian"t"art sous iceweasel, cela semble bien réellement être un problème de résolution sous Linux. 
Édit: L’IP est la même que celle de la page de garde donc c’est un site avec des hôtes virtuels. Cela élimine l’hypothèse anti-linuxiens.
[quote=“mattotop”]En me positionant sur mon routeur (gentoo) donc sans proxy local, j’ai le même problême sous linux.
Mais j’ai vérifié sur mon LAN au boulot, les machines linux passant par mon squid en direct en contournant la transparence posent toujours problême, contrairement à ce que tu dis: le problême existe sous linux en proxy non transparent chez moi.[/quote]Bon, j’ai dit une connerie fran, j’avais fait une faute de frappe, mais quand je tape en direct dans le proxy, ça passe.
Par contre, quand je n’indique pas de proxy, je ne vois pas de requète arriver sous squid transparent, ce qui veut bien dire que l’erreur se situe sur la résolution.
Mais alors pourquoi squid, qui tourne sur une debian qui elle même n’accède pas au site sous lynx, réussi t il à résoudre
Je vais voir si je peux accèder à des logs parlant sur ce qui est demandé à mon dns (interne sous windows), mais demain parceque je n’arrive pas à me connecter au serveur.
Et les versions de noyau ? Après tout il y a une table ARP dedans, non ?
qu’est ce que tu veux que l’arp vienne faire là dedans ?
ça ne concerne que les machines sur le même segment, non (à moins de proxifier, mais c’est un cas spécial) ?
Une fois que la requète arp a échoué, il transmet sa trame au gateway, et on passe ensuite au niveau routage et on ne parle plus d’arp jusqu’à la desserte physique sur le dernier segment, de toutes facon.
Je ne vois pas trop ce que ça pourrait venir faire là dedans.
Bein en fait depuis un bout de temps je pense à la possibilité d’un bug tout bête du type “ne prends que les caractères [a-zA-Z0-9] avant/entre2/après les [.]”, ce genre de chose, c’est pour cela que j’ai pensé à l’ensemble de la chaîne et pas seulement à la partie résolution propre.
C’est sûr que si l’ARP est fautif il ne devrait pas gêner la résolution c’est juste qu’il sera toujours en unknown et donc devrait entraîner la requête au DNS systématiquement (enfin dans l’hypothèse ou ce n’est pas le noyau qui au final fait la requête pour lui-même).
J’ai enlevé la possibilité d’une histoire avec l’UTF-8, car le dash est en ASCII.
Je ne pense pas que tout le monde passe par son propre DNS (belga tu es en direct sur le DNS de ton fournisseur, non ?) donc on devrait pouvoir enlever l’hypothèse bind, à vérifier quand même sur un log.
Édit: Euh, je crois même me rappeller que l’ARP du noyau n’est utilisé que pour la résolution du réseau local et de ce qui est dans resolv.conf, donc probablement pas du tout en cause.
ça signifie? j’ai configuré le wifi basiquement.
Mais je n’ai jamais bidouiller avec le dns
Le serveur de nom crée bien une entrée “createfetch: gui-.deviantart.com A” et va bien demander à a.ns.deviantart.com qui est le serveur de nom primaire de deviantart.
De plus c’est bien servi tel quel et sans faute gui"-".dev…
(J’aurais dû faire cela avant mais j’avais la fléme … 
)
Donc on peut enlever les hypothèses de problèmes d’écriture.
Il suffirait de trouver un autre site avec ce type de nom -..* , comme google n’est d’aucune utilité pour cela, qui c’est qui veux s’y coller ? 
ça signifie? j’ai configuré le wifi basiquement.
Mais je n’ai jamais bidouiller avec le dns[/quote]
Bein voilà, tu viens de me répondre “oui”. 
Je parlais de “si tu avais modifié/ajouté des entrées du type “nameserver w.x.y.z” dans ton /etc/resolv.conf autre que celui de ton fournisseur d’accès”. Visiblement t’as touché à rien donc tu dois avoir le(s) serveur(s) de nom de ton fournisseur dans ce fichier.