Por que o wget é redirecionado para o localhost ao buscar uma página não resolvida?

Question

Eu estou tentando buscar uma página inexistente (nome de host não resolvível) usando wget. Espero que ele falhe, mas isso não acontece.

Aqui está uma transcrição

[mark@cn ~]$ cat /etc/resolv.conf
; google public
nameserver 8.8.8.8
nameserver 8.8.4.4

[mark@cn ~]$ host nonexistent.example.com
Host nonexistent.example.com not found: 3(NXDOMAIN)
[mark@cn ~]$ wget -O - http://nonexistent.example.com/
--2010-09-05 22:12:09--  http://nonexistent.example.com/
Resolving nonexistent.example.com... 205.178.189.131
Connecting to nonexistent.example.com|205.178.189.131|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://127.0.0.1 [following]
--2010-09-05 22:12:09--  http://127.0.0.1/
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 524 [text/html]
Saving to: 'STDOUT'

 0% [                                       ] 0           --.-K/s              
(some HTML that my local Apache serves)
100%[======================================>] 524         --.-K/s   in 0s

2010-09-05 22:12:09 (62.5 MB/s) - '-' saved [524/524]

Por que isso está acontecendo? Alguma idéia?

OS: Centos 5.5 x86_64 Rede: servidores virtuais dedicados cloudnext

Estou perguntando porque tentei o mesmo em código Python e algo semelhante está acontecendo. Algo suspeito está acontecendo e eu não consigo descobrir o quê.

    

Answer 1

Você talvez tenha deixado de fora a parte de seu resolv.conf onde seus domínios de pesquisa estão listados?

Se pelo menos um dos seus domínios de pesquisa tiver entradas curinga (ou seu domínio FQDN do servidor), o que wget realmente resolve é nonexistent.example.com.your.domain.com. . Isso provavelmente leva a um servidor da Web configurado para redirecionar o cliente para o host local, se ele obtiver uma consulta para um VHost desconhecido.

A maneira correta de corrigir isso, na minha opinião, seria não usar domínios curinga ou, pelo menos, não usá-los como domínios de pesquisa. Se, na verdade, o FQDN do seu servidor estiver em um domínio curinga, você poderá solucionar o problema colocando isso em resolv.conf :

options ndots:1
search .

    

Answer 2

Suspeito que o DNS do Google esteja retornando uma resposta para praticamente todas as solicitações. O OpenDNS é semelhante também ... a idéia é que eles podem redirecionar solicitações de host desconhecidas em outros lugares para correção (* tosse) e receita de anúncios (* tosse).

O que acontece se você alterar os servidores DNS para outra coisa? Como 4.2.2.2?

-M

    

Answer 3

Eu me deparei com um sintoma muito semelhante, onde o wget resolveria os endereços para 127.0.0.1. Isso ocorreu apesar de outras máquinas na mesma rede resolverem o endereço corretamente, portanto, ele parecia estar localizado. A máquina com o problema utilizou o cntlm para manipulação de proxy, mas descobriu-se que o processo cntlm não estava sendo executado no momento. Depois de iniciar o processo cntlm, wget funcionava como esperado e resolvido para o endereço correto.