¿Cómo es posible que pueda hacer una búsqueda de host pero no un curl?

20

¿Alguien ha visto esto antes? Tenga en cuenta que esto sucede no solo con google.com, sino con cada dominio que intento. Es una conexión inalámbrica (WEP), pero no estoy seguro de cómo sería relevante:

$ 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

Básicamente, cualquier aplicación, incluido Firefox, no puede funcionar para realizar búsquedas de nombres. Además, si desconecto el wifi y conecto un cable de ethernet, todo está bien.

Daniel Quinn
fuente
1
Tal vez agregue más información, ¿es solo rizo? ¿Qué pasa con wget, navegadores, ping, etc.?
Sandman4
Veo que marcó una respuesta, pero ¿cuál fue exactamente el problema y la solución? ¿Fue un problema de SELinux?
Belmin Fernández el
La "solución" era simplemente que la red parece estar mal hecha. No estoy ejecutando ningún SELinux en la computadora portátil y la "red" solo es administrada por un enrutador wifi comprado en la tienda. Esa respuesta fue la que me ayudó a darme cuenta de que estaba tirando paquetes por todas partes, así que pensé que era algo que no podía resolver y le di el crédito a ese tipo. ¿Por qué tienes una idea mejor?
Daniel Quinn el
pinghace getaddrinfo de llamadas con un poco diferentes parámetros github.com/iputils/iputils/blob/master/ping/ping.c#L574 ai_protocol = IPPROTO_UDP tal que confunde getaddrinfo differnetly alguna manera? Parece que el hostcomando no siempre se usa: unix.stackexchange.com/a/553438/8337
rogerdpack

Respuestas:

8

¿Quizás tenga algunas reglas SELinux (o grsecurity ...) muy raras y restrictivas?

Si no, intente strace -o /tmp/wtf -fF curl -v google.comdetectar desde /tmp/wtfel archivo de salida lo que está sucediendo.

Janne Pikkarainen
fuente
1
Parece que es la conexión wifi en sí. El archivo de salida está LLENO de cosas como esta:9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)
Daniel Quinn
@Daniel Quinn, ¿puedes publicar la salida de /tmp/wtf?
Sachin Divekar
Aquí está la salida: pastebin.com/1y5Z48NK
Daniel Quinn el
Hmm, parece que está haciendo la consulta a 192.168.1.201. ¿Puedes hacer "host google.com 192.168.1.201" por cordura? Básicamente, la búsqueda de DNS específicamente en su servidor DNS.
cjc
Hecho (agregado a la pregunta). Y eso funciona bien, lo que tiene sentido ya que la emisión de host sin un argumento de servidor también funciona correctamente. Parece que solo son llamadas HTTP reales, ya que ICMP (en su mayoría, deja caer el primer ping) funciona.
Daniel Quinn el
8

Usando esto: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

Encontré un comando de teclado que me ayudó a solucionar problemas:

[root @ localhost ~] # wget -6 URL fallida

[root @ localhost ~] # wget -4 URL trabajada

Tiene algo que ver con la pila predeterminada de ipv6 que está causando problemas con ciertas utilidades. Deshabilite ipv6 para resolver.

David T
fuente
5

Revisa tu /etc/nsswitch.conf. Si la hostslínea dice algo como

hosts:      files dns

Estoy tan confundido como tú Pero si dice algo como

hosts:      files

entonces el hecho de que DNS esté funcionando (vea la salida del hostcomando) no ayudará a curl, lo que está haciendo la resolución de nombres a través de las bibliotecas estándar del sistema operativo, a las que se les ha dicho que no usen el DNS.

MadHatter apoya a Monica
fuente
Hmm No había pensado en eso, pero acabo de comprobarlo y dice, files dnsasí que supongo que no es así :-(
Daniel Quinn
1
En el mío, había muchas más cosas en la línea de hosts. "dns" aparece en la lista después de "[NOTFOUND = return]", lo que, según tengo entendido, hace que el sistema regrese no encontrado incluso antes de verificar los servidores DNS configurados. Mover "dns" a antes de que lo no resuelto arreglara mi sistema (tuve que reiniciar).
trebormf
3

Tuve el mismo problema: host, nslookup resuelve bien, curl, no puede con los mismos nombres de host.

Después de la comunicación tcpdumping descubrí que curl intenta establecer una conexión TCP (además de UDP) al puerto DNS, que estaba cerrado en mi enrutador. Después de que se habilitó el puerto tcp 53, curl comenzó a funcionar sin problemas.

Otra cosa extraña es que este problema no aparece si el servidor dns es una instalación de enlace regular. Si uso incrustado en el servidor DNS del enrutador, curl de repente intenta usar los puertos TCP incluso si ya recibió (!) Respuesta a través de UDP 2ms antes. Supongo que esto es un error.

Andrés
fuente
1

Tuve este mismo problema en mi VE (que se ejecuta en mi computadora portátil) hoy, y lo encontré bastante sorprendente. Excava y NSlookup funciona, pero falla la curvatura.

Entonces, por ejemplo:

# 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'

Pero cuando vi la publicación de David T aquí, decidí probarlo con curl. Entonces, mientras esto falla:

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

Esto tiene éxito:

# 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>

El -6 especifica que curl usa IPv6 y el -4, para usar IPv4. Recibo los mismos errores cuando uso wget, así que definitivamente hay algunos problemas con la pila IPv6 en el Host.

Todas las otras modificaciones al archivo nsswitch.conf y otros archivos conf BIND no ayudaron, ya que el problema no es con estas utilidades.

AkinO
fuente
1

Si esto ocurre para cualquiera que intente configurar DNS para una instancia de AWS EC2, asegúrese de habilitar también las reglas IPv6 (:: / 0) para HTTP y HTTPS en el grupo de seguridad utilizado por esa instancia.

David Nathan
fuente
0

¿Tu instalación de rizos fue suave? Si es posible, intente reinstalar curl.

Intente curl -v google.comobtener resultados más detallados para la depuración.

p.ej:

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'

¿Estás obteniendo resultados similares?

Sachin Divekar
fuente
Exactamente lo mismo :-( He actualizado la pregunta con la salida.
Daniel Quinn
0

Podría haber un error en su archivo /etc/resolv.conf que nslookup tolera pero curl no.

La pregunta que se hizo fue "¿Cómo es posible que pueda hacer una búsqueda de host pero no un rizo?"

Esto es posible porque curl usa getaddrinfo () para resolver el FQDN, mientras que nslookup no lo hace. En cambio, creo que nslookup analiza /etc/resolv.conf usando alguna otra función o biblioteca, o mediante su propio código personalizado. No busqué el código fuente para verificar esto, pero puede probarlo agregando espacios en blanco frente al token del servidor de nombres en /etc/resolv.conf. nslookup puede analizar esto pero getaddrinfo () no puede.


Example /etc/resolv.conf
 nameserver 8.8.8.8

Si su resolv.conf tiene este error u otros errores tolerados por nslookup pero no getaddrinfo (), puede resolver un FQDN con nslookup, pero no podrá usar curl en ese FQDN.

Solución: como root, edite /etc/resolv.conf y elimine los espacios en blanco iniciales en la línea del servidor de nombres.

mrjmh
fuente
La stracesalida muestra las consultas DNS que se envían sin recibir respuestas. Eso no es compatible con la hipótesis de un error de análisis en /etc/resolv.conf. Sin embargo, es posible que el recursor sea defectuoso y el uso de un recursor diferente podría ayudar.
kasperd