Comment est-il possible que je puisse faire une recherche d'hôte mais pas une boucle?

Est-ce que quelqu'un a déjà vu ça auparavant? Notez que cela se produit non seulement avec google.com, mais avec chaque domaine que j'essaie. C'est une connexion sans fil (WEP), mais je ne sais pas en quoi cela serait pertinent:

$ curl -v google.com
# This takes about 60s to return
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

$ wget google.com
--2011-11-28 14:44:08--  http://google.com/
Resolving google.com... failed: Name or service not known.
wget: unable to resolve host address `google.com'

$ ping google.com
PING google.com (209.85.148.147) 56(84) bytes of data.
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=2 ttl=54 time=136 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=3 ttl=54 time=34.0 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=4 ttl=54 time=34.3 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=5 ttl=54 time=42.5 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=6 ttl=54 time=44.7 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=7 ttl=54 time=34.5 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7007ms
rtt min/avg/max/mdev = 34.063/54.376/136.026/36.758 ms


$ host google.com
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.

$ host google.com 192.168.1.201
Using domain server:
Name: 192.168.1.201
Address: 192.168.1.201#53
Aliases: 

google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.201

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 wlan0
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0

Fondamentalement, aucune application, y compris Firefox, ne peut fonctionner pour effectuer des recherches de nom. De plus, si je mets le wifi hors ligne et que je branche un câble Ethernet, tout va bien.

Peut-être avez-vous mis en place des règles SELinux (ou grsecurity ...) très étranges et restrictives?

Sinon, essayez strace -o /tmp/wtf -fF curl -v google.comde repérer à partir /tmp/wtfdu fichier de sortie ce qui se passe.

Utilisation de ceci: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

J'ai trouvé un raccourci clavier qui m'a aidé à dépanner:

[root @ localhost ~] # wget -6 URL a échoué

[root @ localhost ~] # wget -4 URL a fonctionné

C'est quelque chose à voir avec la pile ipv6 par défaut qui cause des problèmes avec certains utilitaires. Désactivez ipv6 pour résoudre.

Vérifiez votre /etc/nsswitch.conf. Si la hostsligne dit quelque chose comme

hosts:      files dns

Je suis aussi confus que toi. Mais si ça dit quelque chose comme

hosts:      files

alors le fait que DNS fonctionne (voir la sortie de la hostcommande) n'aidera pas à boucler, qui fait la résolution de noms via les bibliothèques de système d'exploitation standard, qui ont été invitées à ne pas utiliser le DNS.

J'ai eu le même problème - hôte, nslookup résout ok, curl - ne peut pas sur les mêmes noms d'hôtes.

Après la communication tcpdumping, j'ai trouvé que curl essayait d'établir une connexion TCP (en plus d'UDP) au port DNS, qui était fermé dans mon routeur. Après l'activation du port TCP 53, la boucle a commencé à fonctionner sans problème.

Une autre chose étrange est que ce problème n'apparaît pas si le serveur DNS est une installation de liaison régulière. Si j'utilise un serveur DNS intégré au routeur, curl essaie soudainement d'utiliser les ports TCP même s'il a déjà reçu (!) Une réponse via UDP 2 ms auparavant. Je suppose que c'est un bug.

J'ai eu ce même problème sur mon VE (fonctionnant sur mon ordinateur portable) aujourd'hui, et je l'ai trouvé assez surprenant. Dig et NSlookup fonctionnent, mais curl échoue.

Ainsi, par exemple:

# curl -v google.com
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

Mais quand j'ai vu le post de David T ici, j'ai décidé de l'essayer avec curl. Donc, alors que cela échoue:

# curl  google.com -6
curl: (6) Couldn't resolve host 'google.com'

Cela réussit:

# curl  google.com -4
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

Le -6 spécifie que curl utilise IPv6 et le -4, pour utiliser IPv4. J'obtiens les mêmes erreurs lors de l'utilisation de wget, donc certainement des problèmes avec la pile IPv6 sur l'hôte.

Toutes les autres modifications apportées au fichier nsswitch.conf et aux autres fichiers de conf de BIND n'ont pas aidé car le problème n'est pas lié à ces utilitaires.

Si cela se produit pour toute personne essayant de configurer DNS pour une instance AWS EC2, assurez-vous également d'activer les règles IPv6 (:: / 0) pour HTTP et HTTPS dans le groupe de sécurité utilisé par cette instance.

Votre installation de boucle était-elle lisse? Si possible, essayez de réinstaller curl.

Essayez curl -v google.comd'obtenir une sortie plus détaillée pour le débogage.

par exemple:

curl -v dnserror.test
* getaddrinfo(3) failed for dnserror.test:80
* Couldn't resolve host 'dnserror.test'
* Closing connection #0
curl: (6) Couldn't resolve host 'dnserror.test'

Obtenez-vous une sortie similaire?

Il pourrait y avoir une erreur dans votre fichier /etc/resolv.conf que nslookup tolère mais pas curl.

La question posée était "Comment est-il possible que je puisse faire une recherche d'hôte mais pas une boucle?"

Cela est possible car curl utilise getaddrinfo () pour résoudre le nom de domaine complet, contrairement à nslookup. Au lieu de cela, je crois que nslookup analyse /etc/resolv.conf en utilisant une autre fonction ou bibliothèque, ou via son propre code personnalisé. Je n'ai pas regardé le code source pour le vérifier, mais vous pouvez le prouver en ajoutant des espaces devant le jeton du serveur de noms dans /etc/resolv.conf. nslookup peut analyser ceci mais getaddrinfo () ne le peut pas.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Si votre resolv.conf contient cette erreur ou d'autres erreurs tolérées par nslookup mais pas getaddrinfo (), vous pouvez résoudre un nom de domaine complet avec nslookup, mais vous ne pourrez pas utiliser curl sur ce nom de domaine complet.

Correction: en tant que root, modifiez /etc/resolv.conf et supprimez tous les espaces en tête de la ligne du serveur de noms.