nslookup falha, mas o ping é bem-sucedido para domínios inexistentes

Question

Eu tenho dois servidores FreeBSD diferentes (diferentes empresas de hospedagem), ambos exibem esse mesmo comportamento: Eles escolhem um endereço IP específico (216.239.120.238) para cada domínio que NÃO existe.

O nslookup falha como deveria ....

$ nslookup thisdomainsurelydoesntexist.com
Server:         xx.xx.229.3
Address:        xx.xx.229.3#53

** server can't find thisdomainsurelydoesntexist.com: NXDOMAIN

dig me dá:

$ dig thisdomainsurelydoesntexist.com

; <<>> DiG 9.6.-ESV-R5-P1 <<>> thisdomainsurelydoesntexist.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51717
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;thisdomainsurelydoesntexist.com. IN    A

;; AUTHORITY SECTION:
com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1370378827 1800 900 604800 86400

;; Query time: 23 msec
;; SERVER: xx.xx.229.3#53(xx.xx.229.3)
;; WHEN: Tue Jun  4 16:05:02 2013
;; MSG SIZE  rcvd: 122

e o ping me dá:

$ ping thisdomainsurelydoesntexist.com
PING phx2-ss-5-bug616849-lb.cnet.com (216.239.120.238): 56 data bytes
64 bytes from 216.239.120.238: icmp_seq=0 ttl=244 time=25.733 ms
64 bytes from 216.239.120.238: icmp_seq=1 ttl=244 time=20.460 ms
^C
--- phx2-ss-5-bug616849-lb.cnet.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.460/23.096/25.733/2.637 ms

Observe que o nome do host final da escavação, nstld.verisign-grs.com, resolve esse IP.

Qual é a correção?

UPDATE: /etc/resolv.conf tem duas linhas de servidores de nomes, cada uma com um IP (v4) que recebi do meu ISP.

Mas se eu adicionar uma linha "search" ao resolv.conf, o comportamento muda: se "search mydomain.com" (ou seja, meu nome de domínio real), tudo é resolvido e recebo meu próprio IP. Por exemplo, isso faz com que o sitexist.com.my.me permanentemente. Não é bom. Mas se eu configurá-lo para outra coisa, como "search myispdomain.com", então tudo funciona: os domínios existentes resolvem e os inexistentes não.

Mas isso é tudo menos um acidente?

Obrigado pelas sugestões! Aqui está o host -a, e o xx.xx.80.18 IP é o primeiro nameserver em /etc/resolv.conf

$ host -a thisdomainsurelydoesntexist.com
Trying "thisdomainsurelydoesntexist.com"
Received 122 bytes from xx.xx.80.18#53 in 13 ms
Trying "thisdomainsurelydoesntexist.com"
Host thisdomainsurelydoesntexist.com not found: 3(NXDOMAIN)
Received 122 bytes from xx.xx.80.18#53 in 0 ms

Meu ISP me disse que poderia ser porque meu nome de host é da forma "mydomain.com" em vez de "myhost.mydomain.com" (que é sua prática recomendada). Eu pude ver como isso poderia consertar isso. Isso é o que fazer? Nenhuma desvantagem para isso?

Além disso, muito significativamente, devo mencionar que esse código python funciona da mesma maneira que o ping:

import _socket
_socket.getaddrinfo('thisdomainsurelydoesntexist.com', 80)

E muitos outros módulos python são construídos neste núcleo.

    

Answer 1

O sistema (particularmente o glibc, que lida com a resolução de nomes) se comporta de maneira errática quando o nome do host do servidor é um nome de domínio. Na página man do resolv.conf:

A lista de pesquisa é normalmente determinada a partir do nome de domínio local; Por padrão, ele contém apenas o nome do domínio local.

O que isso significa em termos simples é que quando uma pesquisa de domínio falha (depois que nada aparece em / etc / hosts e o resolvedor não retorna um resultado útil) o sistema irá remover alegremente a primeira parte do nome do host - por exemplo, 'abcxyz.com' - e acrescente o restante como um sufixo de pesquisa.

Como '.com' é o sufixo de pesquisa produzido removendo 'abcxyz' do nome do host, o sistema está anexando '.com' como o sufixo de pesquisa para pesquisas com falha, que produz resultados como:

foobar-abcxyz.cz - > foobar-abcxyz.cz.com - > www.czjewelry.com

foobar-abcxyz.com - > foobar-abcxyz.com.com - > www.cnet.com

Para corrigir isso, você provavelmente desejará configurar o nome do host do servidor para um nome de host como 'hostname.abcxyz.com' em vez de 'abcxyz.com' - que, por sua vez, resultará em 'abcxyz.com' sendo anexado como o sufixo de pesquisa por padrão.

Como uma medida provisória, você pode criar uma soma de verificação MD5 aleatória e adicioná-la ao /etc/resolv.conf como uma substituição para o sufixo de pesquisa:

uuidgen | md5sum
e930f5f4ba6ba7868b0cc6718bcef568 -

echo "search e930f5f4ba6ba7868b0cc6718bcef568" >>/etc/resolv.conf

Isso adicionará 'e930f5f4ba6ba7868b0cc6718bcef568' a pesquisas de DNS com falha em vez de '.com' - que, por sua vez, resulta no comportamento padrão de pesquisas com falha para domínios inexistentes. Se você alterar o nome do host para um nome de host real, esta linha poderá ser removida.

    

Answer 2

Alguns servidores de nomes retornam deliberadamente IPs para domínios inexistentes. Os ISPs são notórios por fazer isso - eles podem, na verdade, gerar receita com publicidade em páginas de destino para domínios inexistentes.

Você sempre pode alterar seu arquivo resolv.conf para usar servidores DNS públicos que, com certeza, não exibem esse comportamento. O DNS (8.8.8.8 e 8.8.4.4) do Google e o DNS da Level3 (4.2.2.1 a 4.2.2.6) fornecem acesso público ao DNS e não redirecionam domínios desconhecidos. (Fonte: link )

    

Answer 3

Parece-me que você está usando uma rede que está utilizando um DNS curinga. Isso significa que ele será redirecionado automaticamente para esse endereço IP se um endereço falhar. Você pode testar isso fazendo uma pesquisa no seu navegador. Quando falhar, ele redirecionará você para alguma página de pesquisa patrocinada que está sendo manipulada pelo seu ISP.