Whois: getaddrinfo(whois.nic.or.kr): Nom ou service inconnu

Salut,

À mes touts débuts, bien que j’ai dû l’utiliser très rarement, il me semble que cette commande fonctionner.
Ce qui n’est plus le cas.

(Cf. Indésirables & Firewall)

Quatre heures de recherche sans succès sur la toile, hormis des déclarations de bugs.

Voici.

:~$ whois 219.254.35.83
getaddrinfo(whois.nic.or.kr): Nom ou service inconnu
:~$ 

À partir de ce message d’erreur, sur le web, voilà ce que je peux fournir.

:~# ls -alF /etc/services -rw-r--r-- 1 root root 19666 19 janv. 2011 /etc/services :~#

:~# cat /etc/services| grep whois whois 43/tcp nicname :~#

Mes règles iptables.

[quote]## Whois
iptables -A OUTPUT -p tcp --dport 43 -j ACCEPT
iptables -A OUTPUT -p udp --dport 43 -j ACCEPT
echo “- Autoriser Whois entrant/sortant : [OK]”
[/quote]

[code]:~# strace whois www.google.com

:~#
[/code]
Je n’en sais guère plus, et je ne sais dans quel direction farfouiller … :083

Salut,

Première chose que je vois, tu ne nous donnes pas tes règles pour la chaîne INPUT d’iptables.

Pense à indiquer les “POLICY” par défaut.

Bon courage

Commençons par le commencement :mrgreen:

$ dig whois.nic.or.kr $ dig whois.crsnic.net

Ça n’a probablement rien à voir avec tes règles iptables, voici les miennes (très simples comme tu peux le voir) :

# iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -d 127.0.0.0/8 ! -i lo -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -m state --state INVALID,RELATED,ESTABLISHED,UNTRACKED -j DROP # ! --state NEW -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP # ! --syn -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT ...etc... (uniquement les services locaux que je veux publier)
Si ton POLICY OUTPUT est DROP, avec les règles que tu as données c’est amplement suffisant du moment que tu as bien ta ligne -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT (sans laquelle ta connexion aurait beaucoup de mal à marcher de toutes façons).

[quote=“syam”]Commençons par le commencement :mrgreen:
[/quote]

J’aime ça … :wink:

[code]:~$ dig whois.nic.or.kr

; <<>> DiG 9.7.3 <<>> whois.nic.or.kr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20350
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;whois.nic.or.kr. IN A

;; ANSWER SECTION:
whois.nic.or.kr. 1800 IN A 202.30.50.120

;; Query time: 1462 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Feb 17 14:47:01 2012
;; MSG SIZE rcvd: 49

:~$ [/code]

[code]:~$ dig whois.crsnic.net

; <<>> DiG 9.7.3 <<>> whois.crsnic.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57517
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;whois.crsnic.net. IN A

;; ANSWER SECTION:
whois.crsnic.net. 1 IN A 199.7.52.74

;; Query time: 258 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Feb 17 14:47:13 2012
;; MSG SIZE rcvd: 50

:~$
[/code]

Y’a un truc qui me chiffonne dans ton strace, c’est toutes les lignes sendto/recvfrom en pagaille pour les requêtes DNS.
Chez moi j’ai seulement une requête / réponse :

$ strace whois www.google.com 2>&1 | grep -E 'connect|sendto|recvfrom' | grep -E 'whois|53' connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("217.79.186.148")}, 16) = 0 sendto(3, "\244\325\1\0\0\1\0\0\0\0\0\0\5whois\6crsnic\3net\0\0\1"..., 34, MSG_NOSIGNAL, NULL, 0) = 34 recvfrom(3, "\244\325\201\200\0\1\0\1\0\0\0\0\5whois\6crsnic\3net\0\0\1"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("217.79.186.148")}, [16]) = 50
Sachant que la fonction qui provoque ton erreur (getaddrinfo) sert à résoudre le nom de domaine et numéro de port du service…

[quote=“man getaddrinfo”]int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
DESCRIPTION
Given node and service, which identify an Internet host and a service, getaddrinfo() returns one or more addrinfo structures, each of which contains an Internet address that can be specified in a call to bind(2) or connect(2). The getaddrinfo() function combines the functionality provided by the getservbyname(3) and getservbyport(3) functions into a single interface[/quote]
Ça ressemble quand même un peu à un couac des DNS… :confused:

Il se passe quoi si tu “chauffes” le cache DNS avec un dig, puis que tu fais un whois immédiatement après ?

Ma foi, cela ne chauffe pas, ça coince … :mrgreen:

[code]:~$ dig whois.crsnic.net ; whois www.google.com

; <<>> DiG 9.7.3 <<>> whois.crsnic.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25562
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;whois.crsnic.net. IN A

;; ANSWER SECTION:
whois.crsnic.net. 1 IN A 199.7.59.74

;; Query time: 140 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Feb 17 15:35:52 2012
;; MSG SIZE rcvd: 50

connect: Connexion terminée par expiration du délai d’attente
:~$
[/code]

Bon fais voir ton # iptables -S on sait jamais. :stuck_out_tongue:

Le boxon, je présume … :confused:

:~# iptables -S ... -A OUTPUT -p udp -m udp --dport 43 -j ACCEPT ...

Tu pourrais faire une capture du trafic (tcpdump, wireshark…) lors de l’exécution de whois ?

Effectivement. :confused: Ça vaudrait presque un fil rien que pour faire le tri là-dedans. :smiley:

Par contre je ne vois aucune autorisation pour le port TCP 43 en OUTPUT contrairement à ce que tu as écrit dans ton premier message. Et c’est bien du TCP pour le service whois.

[quote=“PascalHambourg”]Tu pourrais faire une capture du trafic (tcpdump, wireshark…) lors de l’exécution de whois ?
[/quote]

Ce sont deux outils qui sont installés. Mais les utilisaient, c’est autre chose … :083

J’ai fait ce que j’ai pu.

Pour tcpdump, j’y suis allé à la louche avec les options … :033

wireshark, reste un mystère à mes yeux.

[code]:~# tcpdump -nS

:~#
[/code]

[code]:~# tcpdump -nnvvS

:~#
[/code]

L’appellation “lamiennejm.home” (quel nom à la con :mrgreen: ) doit être (je crois) un résidu de mes tous premiers essais de configuration de la box orange. Appellation que ne suis pas fichu de retrouver dans la config actuel.

[code]:~# tcpdump

:~#
[/code]

[code]:~# tcpdump host 192.168.1.12

:~#
[/code]

[code]:~# tcpdump -vvv

:~#
[/code]

[quote=“syam”]…
Ça vaudrait presque un fil rien que pour faire le tri là-dedans.

Par contre je ne vois aucune autorisation pour le port TCP 43 en OUTPUT contrairement à ce que tu as écrit dans ton premier message.
[/quote]

Sais bien ce que je disais :116 j’y mettrai de l’ordre prochainement, depuis que je me le dis … :075 :013

Effectivement, j’ai commis une erreur en retapant la règle à la mano OUTUPU au lieu de OUTPUT, c’est corrigé. Le souci reste présent.

[code]# iptables -S

-A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 43 -j ACCEPT


[/code]

J’en reviens à ta commande strace améliorer @syam

Ce quel me retourne à présent.

[code]:~$ strace whois www.google.com 2>&1 | grep -E ‘connect|sendto|recvfrom’ | grep -E ‘whois|53’

:~$
[/code]

Hmm…
Après étude de la trace réseau, j’ai l’impression que c’est un manifestation du même bug du resolver de la libc déclenché par la mise à jour 6.0.4 de Squeeze avec les serveurs DNS foireux que dans les discussions récentes.
http://www.debian-fr.org/connexions-pages-internet-difficles-t37509.html
http://www.debian-fr.org/couldn-t-resolve-host-a-la-1ere-tentative-pas-a-la-2eme-t37599.html
Peux-tu vérifier/confirmer/infirmer ?

Je ne me suis guère retrouver dans ce type de situation. Tout au plus des petits soucis de connexion sur des pages web (le forum inclus) avec iceweasel et epiphany, mais ce phénomène disparaît avec konqueror.

icedove qu’il me faut relancer à plusieurs reprise, avant d’obtenir le transfert via gmail, ceci depuis la mise à jour 6.0.4

NetworkManager à était remplacé depuis pas mal de mois par ifplugd.

Sinon pas vraiment de ressemblance.

Ça ne te coûte pas cher de tester une des solutions de contournement proposées dans ces discussions (ajout de la ligne “options single-request” ou utilisation d’autres DNS dans /etc/resolv.conf).

Alternative : si tu as défini le dépôt squeeze-updates dans tes sources, fais une mise à jour pour récupérer la dernière version de la libc qui corrige le problème.

Salut,

[quote=“PascalHambourg”] Ça ne te coûte pas cher de tester une des solutions de contournement proposées dans ces discussions (ajout de la ligne “options single-request” ou utilisation d’autres DNS dans /etc/resolv.conf).
[/quote]
Chose qui fût faite hier, avant de poster … :wink:

N’étant pas certain du mode opératoire … :think:

En commentant squeeze et ne laissant que squeeze-updates (la modification du pinning n’a rien changer) voici ce que j’obtiendrai.

...
## squeeze
#deb http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
#deb-src http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
...
# squeeze update
deb http://ftp.fr.debian.org/debian/ squeeze-updates main contrib non-free
#deb-src http://ftp.fr.debian.org/debian/ squeeze-updates main contrib non-free
...
:~$ acp libc6
libc6:
  Installé : 2.11.3-2
  Candidat : 2.11.3-2
 Table de version :
     2.13-26 0
         90 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages
         50 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages
     2.11.3-3 0
        500 http://ftp.fr.debian.org/debian/ squeeze-updates/main amd64 Packages
        500 http://ftp.fr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
 *** 2.11.3-2 0
        990 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages
        100 /var/lib/dpkg/status
     2.7-18lenny7 0
        500 http://ftp.fr.debian.org/debian/ lenny/main amd64 Packages
        500 http://security.debian.org/ lenny/updates/main amd64 Packages
:~$ 
:~# aptitude -s upgrade
Résolution des dépendances...                 
ouverts : 599 ; fermés : 178 ; reportés : 185 ; en conflit : 135                                                                                                         .Les NOUVEAUX paquets suivants vont être installés : 
  libavcodec53{a} libavformat53{a} libavutil-extra-51{a} libpostproc-extra-52{a} libswscale-extra-2{a} libx264-116{a} linux-image-2.6.26-2-amd64{a} linux-image-amd64{a} 
  nvidia-installer-cleanup{a} nvidia-kernel-2.6.32-5-amd64{a} 
Les paquets suivants seront ENLEVÉS : 
  libgtkglext1{u} 
Les paquets suivants seront mis à jour : 
  browser-plugin-gnash dkms dpkg-dev gnash gnash-common gstreamer0.10-ffmpeg initramfs-tools libc-bin libc-dev-bin libc6 libc6-dev libc6-i386 libdpkg-perl libgeoip1 
  libgl1-mesa-glx libglu1-mesa libgps19 libjs-jquery libkeyutils1 libnfsidmap2 libnspr4-0d libsane libsane-extras libsmbclient libtdb1 libwbclient0 libxapian22 linux-base 
  linux-image-2.6-amd64 linux-libc-dev locales memtest86+ mutt nvidia-kernel-common nvidia-kernel-dkms nvidia-settings procps python-mako rkhunter sane-utils xserver-common 
Les paquets suivants sont RECOMMANDÉS mais ne seront pas installés :
  libalgorithm-merge-perl libgl1-nvidia-legacy-173xx-glx libgl1-nvidia-legacy-71xx-glx libgl1-nvidia-legacy-96xx-glx manpages-dev 
41 paquets mis à jour, 10 nouvellement installés, 1 à enlever et 40 non mis à jour.
Il est nécessaire de télécharger 75,0 Mo d'archives. Après dépaquetage, 116 Mo seront utilisés.
Voulez-vous continuer ? [Y/n/?] y
Charger/installer/enlever des paquets.
:~# 

Ne serait-il pas souhaitable à l’avenir de ne laisser que le dépôt squeeze-updates régir mes paquets ?

Pour l’heure, je lance une sauvegarde.

Peux tu confirmer pour cette mise à jour … :083

Sans amélioration ? Pourtant la réponse “not implemented” du serveur DNS à une requête de type AAAA (adresse IPv6) arrivant avant la réponse à la requête de type A (adresse IPv4), qu’on peut retrouver dans tes captures, est typique de la description du problème que j’ai pu lire dans les rapports de bugs.

Si tu combines des sources de plusieurs versions de Debian, je ne confirme rien du tout. Je n’utilise que Debian stable pure. Je confirme juste que la version de la libc censée corriger le problème est bien 2.11.3-3 présente sur squeeze-update, mais bizarrement chez toi apt-cache policy ne la choisit pas comme candidate, et pourtant aptitude upgrade montre bien une mise à jour des paquets libc6…

Aucune, mon fichier /etc/resolv.conf modifié.

:~# cat /etc/resolv.conf
domain home
search home
nameserver 192.168.1.1
nameserver 80.10.246.2
nameserver 80.10.246.129
# ligne rajoutée - 17/02/2012
# voir https://www.debian-fr.org/connexions-pages-internet-difficles-t37509.html
options single-request

:~# 

J’oublierai ça, si je passe le mise à jour de libc6 tel que citer ci-plus-haut, je dé-commenterai squeeze en lieu et place de squeeze-update.

Concernant la version candidate de libc6, je dois avoir une poutre dans l’œil tellement cela doit être énorme, je passe à côté de je ne sais quoi …

Mon preferences.

Or apt-cache policy ne chante pas le même refrain …

Confirmé par apt-cache policy libc6.

Il y a un truc qui m’échappe, la poutre certainement … :think:

Évidemment qu’apt-cache policy ne réagit pas correctement…

[quote]Package: *
Pin: release o=Debian,a=squeeze-updates,l=Debian
Pin-Priority: 990

Package: *
Pin: release o=Debian,a=squeeze-proposed-updates,l=Debian
Pin-Priority: 990[/quote]

[quote]500 ftp.fr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
release v=6.0-updates,o=Debian,a=proposed-updates,n=squeeze-proposed-updates,l=Debian,c=main
origin ftp.fr.debian.org
500 ftp.fr.debian.org/debian/ squeeze-proposed-updates/contrib amd64 Packages
release v=6.0-updates,o=Debian,a=proposed-updates,n=squeeze-proposed-updates,l=Debian,c=contrib
origin ftp.fr.debian.org
500 ftp.fr.debian.org/debian/ squeeze-proposed-updates/non-free amd64 Packages
release v=6.0-updates,o=Debian,a=proposed-updates,n=squeeze-proposed-updates,l=Debian,c=non-free
origin ftp.fr.debian.org
500 ftp.fr.debian.org/debian/ squeeze-updates/non-free amd64 Packages
release o=Debian,a=stable-updates,n=squeeze-updates,l=Debian,c=non-free
origin ftp.fr.debian.org
500 ftp.fr.debian.org/debian/ squeeze-updates/contrib amd64 Packages
release o=Debian,a=stable-updates,n=squeeze-updates,l=Debian,c=contrib
origin ftp.fr.debian.org
500 ftp.fr.debian.org/debian/ squeeze-updates/main amd64 Packages
release o=Debian,a=stable-updates,n=squeeze-updates,l=Debian,c=main
origin ftp.fr.debian.org[/quote]
:wink:

D’ailleurs, le proposed-updates n’est pas forcément une bonne idée, vu qu’il s’agit d’une zone temporaire pour les mises à jour avant qu’elles ne soient validées par l’équipe Debian. debian.org/releases/proposed-updates