A pesquisa do nome do host falha, o servidor de nomes está configurado corretamente

Question

Temos uma rede pequena, com um servidor principal (hospedando nosso próprio site e funcionando como um servidor de nomes) e alguns servidores de hospedagem na web. Desde ontem, temos um problema com um domínio de um cliente nosso que hospedamos em nossa rede.

O servidor da Web está configurado corretamente, o servidor de nomes também (e ambos funcionam bem para outros domínios), mas o domínio está inacessível porque a pesquisa de nome de host falha. O Chrome diz que o nome do host não pôde ser resolvido, algumas ferramentas de verificação do DNS informam que o domínio não foi encontrado ou simplesmente caiu.

Quando executo o comando dig directgeslaagd.com , recebo apenas uma seção de autoridade, dizendo com 600 IN SOA a.gtld-... , que é para o TLD. Quando executo o comando dig @ns1.webwhales.nl directgeslaagd.com , obtenho os resultados corretos ( directgeslaagd.com. 86400 IN A 149.210.185.13 ). Isso acontece de dentro e de fora da nossa rede de servidores. Então, a minha conclusão é que meu servidor de nomes funciona corretamente, né?

Quando eu ajustar o arquivo de hosts do meu PC com Windows e carregar este domínio diretamente do 149.210.185.13, o site funciona, a conclusão é que o servidor da Web também funciona corretamente. Quando procuro os dados do WHOIS, todos os servidores de nomes e dados estão corretos. Ontem atualizei os detalhes do servidor de nomes por meio de nosso registrador, mas isso não ajudou.

Você sabe qual pode ser o problema aqui? Eu nunca vi algo assim antes. Os domínios usados aqui são os domínios reais, para que você possa ver por si mesmo.

    

Answer 1

Recebi uma resposta do meu registrador. Acontece que a ICANN envia um email de verificação quando o endereço de email do titular do domínio é alterado. Eles fazem isso para todos os seus TLDs há alguns meses. Dá-lhe uma a duas semanas para clicar no link desse email ou o seu domínio será bloqueado.

Quando esse for o caso, o status do registrador nos dados do WHOIS deve ser clientHold . Ironicamente, esse e-mail geralmente desaparece na caixa de spam do destinatário. Seria bom se eles enviassem um alerta para o contato técnico (ou pelo menos outro endereço de e-mail registrado com esse domínio) primeiro.

Espero que isso ajude outras pessoas.

    

Answer 2

É melhor pensar em WHOIS como uma ferramenta de informação de "melhor esforço" para humanos. As informações fornecidas nem sempre são atuais ou precisas e, em ambos os casos, não é algo que o DNS sempre consulte.

dig +trace +additional example.com é seu amigo; ajuda-o a visualizar problemas e mostrará coisas que o WHOIS nunca fará. Isso inicia um rastreio nos servidores de nomes raiz e segue as delegações do servidor de nomes.

No seu caso particular, isso é o mais possível para o rastreamento:

com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1425204658 1800 900 604800 86400
;; Received 112 bytes from 192.33.14.30#53(192.33.14.30) in 11 ms

Isso deve estar tocando: isso é muito parecido com o que você estava vendo com sua escavação anterior. (uma seção de autoridade para com. e seu registro SOA) O problema é que os servidores de nomes de TLDs para com. não estão servindo uma delegação para outros servidores de nomes.

Aqui é onde as informações do WHOIS finalmente se tornam úteis: directgeslaagd.com. não expirou (válido até dezembro de 2016), e supostamente existem três servidores de nomes configurados ... mas isso não é um reflexo válido do que os servidores de nomes de TLD estão realmente servindo quando recebem a consulta.

O problema está em algum lugar entre a interface da web do registrador e os servidores de nomes de DPNs. Tente encontrar algo dentro da interface da Web do registrador que possa sugerir por que isso está acontecendo. Além disso, você precisará levar isso ao seu registrador diretamente, pois eles são os únicos que podem fornecer uma resposta direta sobre qual é o problema.