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

¿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.

¿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.

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.

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.

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.

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.

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.

¿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?

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.