Como é possível que eu possa fazer uma pesquisa de host, mas não uma onda?

Question

Alguém já viu isso antes? Observe que isso acontece não apenas com o google.com, mas com todos os domínios que eu experimento. É uma conexão sem fio (WEP), mas não tenho certeza de como isso seria 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

Basicamente, qualquer aplicativo, incluindo o Firefox, não pode trabalhar para fazer pesquisas de nome. Além do mais, se eu tirar o wifi offline e conectar um cabo ethernet, está tudo bem.

    

Answer 1

Talvez você tenha regras muito estranhas e restritivas do SELinux (ou grsecurity ...) em vigor?

Se não, tente strace -o /tmp/wtf -fF curl -v google.com e tente identificar do arquivo /tmp/wtf output o que está acontecendo.

    

Answer 2

Usando isto: link

Encontrei um comando-chave que me ajudou a solucionar problemas:

[root @ localhost ~] # wget -6 URL com falha

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

Tem algo a ver com a pilha ipv6 padrão que está causando problemas com certos utilitários. Desativar o ipv6 para resolver.

    

Answer 3

Verifique seu /etc/nsswitch.conf . Se a linha hosts disser algo como

hosts:      files dns

Estou tão confuso quanto você. Mas se diz algo como

hosts:      files

então o fato de o DNS estar funcionando (veja a saída do comando host ) não ajudará o curl, que está fazendo a resolução de nomes através das bibliotecas padrão do SO, que foram instruídas a não usar o DNS.

    

Answer 4

Eu tive o mesmo problema - host, nslookup resolve ok, curl - não pode nos mesmos nomes de host.

Após a comunicação do tcpdumping, descobri que o curl tenta estabelecer conexão TCP (além do UDP) à porta DNS, que foi fechada no meu roteador. Depois que o tcp porta 53 foi ativado, o curl começou a funcionar perfeitamente.

Outra coisa estranha é que esse problema não aparece se o servidor dns for uma instalação de ligação regular. Se eu usar incorporado no servidor DNS do roteador, o curl de repente tentará usar as portas TCP, mesmo que ele já tenha recebido (!) Resposta via UDP 2 ms antes. Eu suponho que isso seja um bug.

    

Answer 5

Eu tive esse mesmo problema no meu VE (rodando no meu laptop) hoje e achei bastante surpreendente. Dig e NSlookup funciona, mas a onda falha.

Então, por exemplo:

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

Mas quando vi o post do David T aqui, decidi experimentar com o curl. Então, enquanto isso falhar:

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

Isso é bem-sucedido:

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

O -6 especifica que o curl usa o IPv6 e o -4, para usar o IPv4. Eu recebo os mesmos erros ao usar o wget, então definitivamente alguns problemas com a pilha do IPv6 no host.

Todas as outras modificações no arquivo nsswitch.conf e outros arquivos conf do BIND não ajudaram, já que o problema não está nos utilitários.

    

Answer 6

Poderia haver um erro em seu arquivo /etc/resolv.conf que o nslookup tolera, mas o curl não.

A pergunta feita foi "Como é possível fazer uma pesquisa de host, mas não uma onda?"

Isso é possível porque o curl usa getaddrinfo () para resolver o FQDN, enquanto o nslookup não. Em vez disso, acredito que o nslookup analisa o /etc/resolv.conf usando alguma outra função ou biblioteca, ou através de seu próprio código customizado. Eu não olhei para o código-fonte para verificar isso, mas você pode provar isso adicionando espaços em branco na frente do token do servidor de nomes em /etc/resolv.conf. O nslookup pode analisar isso, mas o getaddrinfo () não pode.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Se o seu resolv.conf tiver esse erro ou outros erros tolerados pelo nslookup, mas não pelo getaddrinfo (), você poderá resolver um FQDN com o nslookup, mas não poderá usar o curl nesse FQDN.

Corrigir: como root, edite /etc/resolv.conf e remova qualquer espaço em branco na linha do servidor de nomes.

    

Answer 7

Sua instalação de onda foi suave? Se possível, tente reinstalar o curl.

Teste curl -v google.com para obter uma saída mais detalhada para depuração.

por exemplo:

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'

Você está recebendo resultados semelhantes?