Eu tenho dois servidores web no nosso colocation rodando o CentOS 6.0. Um executa nosso principal site de marketing (servidor de produção) e o outro é um servidor de teste para o servidor de produção, portanto, quase uma réplica exata. Ambos estão atrás de um firewall e possuem endereços IP privados. O firewall está conectado ao nosso escritório principal com um tunnell VPN site-a-site. Ambos os servidores têm seus servidores de nomes configurados para usar nossos servidores DNS internos aqui em nosso escritório principal.
No servidor de produção, estou enfrentando exatamente o mesmo problema , até mesmo o mesmo hostname de phx1-ss-2-lb.cnet.com. O problema é que sempre que eu pingar um nome de domínio que não existe, recebo o nome do host cnet.com em troca. Mesmo em meus próprios domínios, se eu fizer somupupidossubdominio.meudominio.com, ele retornará com o endereço da cnet. Nesse segmento, eles disseram que era o seqüestro do NXDOMAIN e que eles deveriam usar servidores de nomes diferentes. Na minha situação, este servidor de produção está usando os mesmos servidores de nomes que todos os outros da empresa, mas isso não é problema para ninguém. Mesmo o servidor de temporariedade que é um espelho do servidor de produção não está tendo o problema.
Eu verifiquei o arquivo / etc / hosts e nada fora do comum está lá. Eu olhei como liberar o cache DNS local por meio de nscd ou vincular e nem sequer são instalados. Eu usei o nslookup e consultei meus dois servidores DNS designados e eles retornaram com erros de domínio não encontrados, como seria de se esperar.
Onde devo procurar agora?
EDITAR
Eu usei o tcpdump na porta 53 e, em vez de pingar algum domínio jibberish, esta é a saída que obtive
14:55:39.884442 IP 192.168.4.11.59726 > 192.168.0.22.domain: 27749+ A? asdfjjjf.com. (30) 14:55:39.905778 IP 192.168.0.22.domain > 192.168.4.11.59726: 27749 NXDomain 0/1/0 (103) 14:55:39.905930 IP 192.168.4.11.46752 > 192.168.0.22.domain: 18476+ A? asdfjjjf.com.com. (34) 14:55:39.926982 IP 192.168.0.22.domain > 192.168.4.11.46752: 18476 2/0/0 CNAME phx1-ss-2-lb.cnet.com., A 64.30.224.112 (82)
14:55:39.962067 IP 192.168.4.11.44686 > 192.168.0.22.domain: 5275+ PTR? 112.224.30.64.in-addr.arpa. (44)
14:55:39.983324 IP 192.168.0.22.domain > 192.168.4.11.44686: 5275 1/0/0 PTR phx1-ss-2-lb.cnet.com. (79)
Então, se estou lendo isso corretamente, isso significa que meu servidor DNS está respondendo definitivamente com o endereço cnet.com? Se eu usar o nslookup, configure-o para o servidor 192.168.0.22 e consulte um registro A do tipo jibberish domains, ele retornará sem nada.
Aha! Você tem um sufixo de pesquisa de com - sua primeira consulta para asdfjjjf.com obteve o NXDOMAIN adequado, enquanto a segunda para asdfjjjf.com.com voltou com as informações precisas do que é aparentemente um curinga CNAME at *.com.com . Largue esse sufixo de pesquisa e você ficará bem.
Agora há uma discussão mais detalhada em andamento em
Usar "strace" em "ping" deixou claro que o problema realmente está nas bibliotecas locais. O rastreio mostra as chamadas de DNS e a biblioteca local realmente está inserindo um ".com" extra nas tentativas de solicitação de DNS. O rastreamento mostra claramente que a biblioteca fez uma solicitação de DNS de "noexample.com", depois tentou "noexample.com.com" e, em seguida, usou o resultado de "noexample.com.com" para fazer ping.
Eu vi exatamente a mesma situação em um servidor dedicado co-localizado no Codero. É um servidor dedicado completo, o CentOS 6 de 64 bits, sem virtualização, administrado com o Webmin. Não é executado "nomeado"; todas as consultas DNS são enviadas para os servidores DNS internos do Codero. Como no exemplo acima, "ping" (e qualquer coisa que use getaddrinfo), dado um domínio inexistente em ".com", retorna um host na CNET:
ping noexample.com PING phx1-ss-2-lb.cnet.com (64.30.224.112) 56(84) bytes of data. 64 bytes from phx1-ss-2-lb.cnet.com (64.30.224.112): icmp_seq=1 ttl=246 time=11.8 ms 64 bytes from phx1-ss-2-lb.cnet.com (64.30.224.112): icmp_seq=2 ttl=246 time=12.0 ms
No entanto, "nslookup" e "host" não encontram "noexample.com". Então os servidores DNS do Codero não são Fazendo isso.
/etc/resolv.conf (gerado pelo WebMin) é exatamente isso:
servidor de nomes 69.64.66.11 servidor de nomes 69.64.66.10
Se eu tentar "noexample.net", ele não encontrará um endereço IP. É apenas um problema .com.
Eu notei que "getaddrinfo" agora tenta colocar um ".com" no final das coisas que não resolvem. Se eu tentar resolver "example", ele encontrará "example.com". Então eu obtenho a idéia de um recorde.
Isto parece um bug em "getaddrinfo". Nunca deve adicionar ".com" a algo que já tenha.
Veja o que está acontecendo.
Eu acho que vejo o que está acontecendo. Veja a man page para "resolv.conf:
Observe qual é o padrão:
domain Nome do domínio local. A maioria das consultas de nomes nesse domínio pode usar nomes abreviados relativos ao domínio local. Se nenhuma entrada de domínio estiver presente, o domínio será determinado a partir do nome do host local retornado por gethostname (2); a parte do domínio é considerada tudo após o primeiro '.' Finalmente, se o nome do host não contém uma parte do domínio, o domínio raiz é assumido.
Nesse caso, o nome padrão do servidor é "sitetruth.com". Então a "parte do domínio" é ".com", e todas as pesquisas com falha são repetidas com o ".com" anexado.
Por que isso não acontece o tempo todo? Porque a maioria dos servidores tem nomes atribuídos por alguma hospedagem serviço, como "gator123.hostgator.com". Nesses casos, o domínio padrão é "hostgator.com", e é isso que é adicionado em pesquisas de domínio com falha. Se o seu servidor tiver um nome de dois componentes como seu nome principal, porém, há um problema.
O padrão em "resolv" é mal escolhido.
Voltando à pergunta original, em que o problema ocorreu apenas no servidor de produção, Aposto que o servidor de produção tem um nome como "companyname.com", enquanto o servidor de teste tem um nome mais longo, como "test.companyname.com". Isso é o suficiente para criar essa situação.
Definir "ndots" como 0 ou fornecer uma linha de "pesquisa" vazia deve desativar esse comportamento, mas até agora, não está fazendo isso. Então eu não tenho uma correção ainda.