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

20

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.

domain-name-system wifi curl Daniel Quinn
la source
1
Peut-être ajouter quelques informations supplémentaires - est-ce que c'est juste bouclé? Qu'en est-il de wget, des navigateurs, du ping, etc.?
Sandman4
Je vois que vous avez marqué une réponse, mais quel était exactement le problème et la solution? Était-ce un problème SELinux?
Belmin Fernandez
La «solution» était simplement que le réseau semble être gribouillée à droite. Je n'exécute aucun SELinux sur l'ordinateur portable et le "réseau" est simplement géré par un routeur wifi acheté en magasin. Cette réponse a été celle qui m'a aidé à comprendre que je laissais tomber des paquets partout, alors j'ai pensé que c'était quelque chose que je ne pouvais pas résoudre et j'ai donné à ce gars le mérite. Pourquoi avez-vous une meilleure idée?
Daniel Quinn
pingappelle getaddrinfo avec des paramètres légèrement différents github.com/iputils/iputils/blob/master/ping/ping.c#L574 ai_protocol = IPPROTO_UDP peut-être que cela confond getaddrinfo différemment d'une manière ou d'une autre? Il semble que la hostcommande ne soit pas toujours utilisée non plus: unix.stackexchange.com/a/553438/8337
rogerdpack

Réponses:

8

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.

Janne Pikkarainen
la source
1
On dirait que c'est la connexion wifi elle-même. Le fichier de sortie est plein de trucs comme ça:9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)
Daniel Quinn
@Daniel Quinn, pouvez-vous publier la sortie de /tmp/wtf?
Sachin Divekar
Voici la sortie: pastebin.com/1y5Z48NK
Daniel Quinn
Hmm, on dirait qu'il fait la requête à 192.168.1.201. Pouvez-vous faire "héberger google.com 192.168.1.201" pour raison? Fondamentalement, la recherche DNS spécifiquement contre votre serveur DNS.
cjc
Terminé (l'ajoute à la question). Et cela fonctionne très bien - ce qui est logique puisque l'émission d'hôte sans argument serveur fonctionne également correctement. Il semble que ce ne soient que des appels HTTP réels, car ICMP (principalement, il supprime le premier ping) fonctionne.
Daniel Quinn,
8

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.

David T
la source
5

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.

MadHatter soutient Monica
la source
Hmm. Je n'y avais pas pensé, mais je viens de vérifier et ça dit files dnsdonc je suppose que ce n'est pas ça :-(
Daniel Quinn
1
Dans le mien, il y avait beaucoup plus de choses sur la ligne d'hôtes. "dns" a été répertorié après "[NOTFOUND = return]", ce qui, à ma connaissance, fait que le système retourne introuvable avant même de vérifier les serveurs DNS configurés! Déplacer "DNS" avant la chose non trouvée a corrigé mon système (a dû redémarrer).
trebormf
3

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.

Andrew
la source
1

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.

AkinO
la source
1

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.

David Nathan
la source
0

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?

Sachin Divekar
la source
Exactement la même :-( J'ai mis à jour la question avec la sortie.
Daniel Quinn
0

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.

mrjmh
la source
La stracesortie affiche les requêtes DNS envoyées sans recevoir de réponses. Cela ne prend pas en charge l'hypothèse d'une erreur d'analyse sur /etc/resolv.conf. Cependant, il est possible que le récurseur soit défectueux et l'utilisation d'un récurseur différent pourrait aider.
kasperd