Como é possível fazer uma pesquisa no host, mas não um curl?

20

Alguém já viu isso antes? Observe que isso acontece não apenas no google.com.br, mas em todos os domínios que eu tento. É 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 funciona para pesquisar nomes. Além disso, se eu desligar o Wi-Fi e conectar um cabo Ethernet, está tudo bem.

domain-name-system  wifi  curl 
— Daniel Quinn
fonte
11
Talvez adicione mais algumas informações - é apenas enrolar? E o wget, navegadores, ping etc.?
— Sandman4
Vejo que você marcou uma resposta, mas qual foi exatamente o problema e a solução? Foi um problema do SELinux?
— Belmin Fernandez
A "solução" era justamente que a rede parece estar correta. Não estou executando nenhum SELinux no laptop e a "rede" é gerenciada apenas por um roteador wifi comprado na loja. Essa resposta foi a que me ajudou a descobrir que eu estava jogando pacotes em todo o lugar, então achei que era algo que não conseguia resolver e dei crédito a esse cara. Por que você tem uma ideia melhor?
— Daniel Quinn
pingchama getaddrinfo com parâmetros ligeiramente diferentes github.com/iputils/iputils/blob/master/ping/ping.c#L574 ai_protocol = IPPROTO_UDP talvez isso confunda getaddrinfo diferentemente de alguma forma? Parece que o hostcomando nem sempre é usado: unix.stackexchange.com/a/553438/8337
— rogerdpack

Respostas:

8

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

Caso contrário, tente strace -o /tmp/wtf -fF curl -v google.comidentificar no /tmp/wtfarquivo de saída o que está acontecendo.

— Janne Pikkarainen
fonte
11
Parece que é a própria conexão wifi. O arquivo de saída está CHEIO de coisas assim:9344 poll([{fd=3, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 1000) = 0 (Timeout)
— Daniel Quinn
@ Daniel Quinn, você pode postar a saída de /tmp/wtf?
— Sachin Divekar
Aqui está a saída: pastebin.com/1y5Z48NK
— Daniel Quinn
Hmm, parece que está fazendo a consulta até 192.168.1.201. Você pode "hospedar google.com 192.168.1.201" por sanidade? Basicamente, pesquisa de DNS especificamente no seu servidor DNS.
— CJC
Concluído (adicionado à pergunta). E isso funciona muito bem - o que faz sentido, pois a emissão de host sem um argumento de servidor também funciona corretamente. Parece que também são apenas chamadas HTTP reais, já que o ICMP (principalmente, descarta o primeiro ping) funciona.
— Daniel Quinn
5

Verifique o seu /etc/nsswitch.conf. Se a hostslinha diz algo como

hosts:      files dns

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

hosts:      files

o fato de o DNS estar funcionando (consulte a saída do hostcomando) não ajudará a se curvar, o que está resolvendo os nomes por meio das bibliotecas padrão do SO, que foram instruídas a não usar o DNS.

— MadHatter apoia Monica
fonte
Hmm. Eu não tinha pensado nisso, mas eu verifiquei e ele diz files dnsentão eu acho que não é isso :-(
— Daniel Quinn
11
Na minha, havia muito mais coisas na linha de hosts. "dns" foi listado após "[NOTFOUND = return]" que, no meu entendimento, faz com que o sistema retorne não encontrado antes mesmo de verificar os servidores DNS configurados! Mover "dns" para antes da coisa não encontrada consertar meu sistema (tive que reiniciar).
— trebormf
3

Eu tive o mesmo problema - host, o 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 a conexão TCP (além do UDP) à porta DNS, que foi fechada no meu roteador. Depois que a porta 53 do tcp foi ativada, 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 uso incorporado no servidor DNS do roteador, o curl tenta repentinamente usar portas TCP, mesmo que já tenha recebido (!) Resposta via UDP 2ms antes. Suponho que isso seja um bug.

— Andrew
fonte
1

Hoje eu tive esse mesmo problema no meu VE (executando no meu laptop) e achei bastante surpreendente. Dig e NSlookup funcionam, mas a curvatura 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 de David T aqui, decidi experimentá-lo com 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 IPv6 no host.

Todas as outras modificações no arquivo nsswitch.conf e em outros arquivos conf BIND não ajudaram, pois o problema não ocorre com esses utilitários.

— AkinO
fonte
1

Se isso ocorrer para qualquer pessoa que tente configurar o DNS para uma instância do AWS EC2, ative também as regras IPv6 (:: / 0) para HTTP e HTTPS no grupo de segurança usado por essa instância.

— David Nathan
fonte
0

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

Tente curl -v google.comobter 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á obtendo resultados semelhantes?

— Sachin Divekar
fonte
Exatamente o mesmo :-( Eu atualizei a questão com a saída.
— Daniel Quinn
0

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

A pergunta foi: "Como é possível fazer uma pesquisa no host, mas não um curl?"

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 /etc/resolv.conf usando alguma outra função ou biblioteca, ou através de seu próprio código personalizado. Não procurei o código-fonte para verificar isso, mas você pode prová-lo adicionando espaço em branco na frente do token do servidor de nomes em /etc/resolv.conf. O nslookup pode analisar isso, mas 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 (), será possível resolver um FQDN com o nslookup, mas você não poderá usar o curl nesse FQDN.

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

— mrjmh
fonte
A stracesaída mostra as consultas DNS sendo enviadas sem receber respostas. Isso não suporta a hipótese de um erro de análise /etc/resolv.conf. No entanto, é possível que o recursor esteja com defeito e o uso de um recursor diferente pode ajudar.
— kasperd
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.