Testando o DNS “saúde” - se os domínios estão apontando para os IPs corretos

Question

Estou planejando mudar de um registrador para outro. Felizmente, consegui inserir previamente as informações da zona para que, quando a transferência ocorrer, tudo se comporte da mesma forma.

No entanto, tendo sido gravada no passado, estou um pouco paranoica e quero poder configurar sistemas de monitoramento com antecedência para garantir que os domínios continuem apontando para os mesmos locais.

A minha preocupação é, como faço para definir algo parecido sem se deparar com a questão das pesquisas de DNS em cache? Eu realmente quero que cada pesquisa seja nova para que não haja problemas.

Então, acho que estou procurando duas coisas:

1. uma ferramenta confiável para testar pesquisas de DNS (uma que por razões óbvias não está hospedada em nenhum dos meus servidores, pois há o perigo de não conseguirem me enviar um email quando algo vai mal) e
2. um teste que não extrai um registro em cache e mantém as informações de DNS atualizadas e atualizadas

Além disso, estou assumindo que tudo ficará bem para servidores em cache, já que os novos registros correspondem aos antigos. Mas há algo perigoso nessa suposição? Existe alguma razão para pensar que a mudança de registradores e servidores de nomes ao mesmo tempo possa ter efeitos colaterais que eu não conheço?

Como foi, caso alguém esteja interessado

Aparentemente, durante a transferência, os servidores de nomes antigos foram mantidos, então por algum tempo nenhum dos domínios apontou para um IP (acho que assim que a transferência ocorrer, o antigo registrador apaga sua registros). Eu tive que atualizar esses registros para apontar para os novos servidores de nomes e reimportar todos os registros da zona (felizmente o sistema do novo registrador tem uma boa ferramenta de importação para arquivos de zona, muito útil!). Por algum motivo estranho, o servidor de nomes local do serviço de hospedagem da Web levou muito mais tempo do que outros servidores DNS para atualizar seus registros, de modo que o próprio servidor ficou confuso sobre quais registros ele poderia atender. Se alguém mais estiver passando pelo mesmo processo, aqui estão algumas coisas que você deve fazer para evitar o que passei:

1. Certifique-se de que os registros da zona são funcionalmente idênticos em todos os registradores. [Mas veja abaixo]. Infelizmente, um registro que deveria ser um registro A foi armazenado como um registro CNAME com resultados ruins. Isso é fácil para os registradores que permitem exportar seus registros como um arquivo de zona, difícil para aqueles que têm apenas uma página da Web que você precisa recortar e colar.
2. Certifique-se de que o novo registrador está definitivamente configurado para ser o novo host DNS Por algum motivo, durante o processo de transferência, não configurei corretamente o domínio para ser hospedado por DNS pelo novo registrador. Isso ocorreu durante o processo de carrinho de compras, não uma etapa de configuração após a compra. Aparentemente, o que eu precisava ter feito naquele momento era cancelar a solicitação de transferência e começar de novo, porque não havia como alterá-la para que ativasse a ativação.
3. Certifique-se de que, quando a transferência de domínio for concluída, você esteja configurado para receber um alerta . Não descobri que a transferência ocorreu até que um dos domínios parou de funcionar porque não estava configurado como o contato autorizado para o domínio.
4. Acima de tudo, tente não estar na metade de uma viagem de carro de oito horas com sua família quando a transferência finalmente passar . Graças a Deus Dunkin Donuts tem WiFi grátis - quem sabia? (Ah, e isso realmente complicou o teste do DNS na época, já que eu não podia usar servidores proxy para testar consultas DNS de vários locais, já que os proxies da Web são bloqueados pelo software usado pela Dunkin Donuts para fornecer acesso WiFi).

Algumas coisas que eu fiz acertaram depois de tudo:

1. Substituir cargas de registros A por registros CNAME . Isso provavelmente teria sido muito mais difícil de administrar se eu tivesse que acompanhar dezenas de registros A idênticos. Além disso, eu só precisava me preocupar com alguns domínios propagando corretamente, já que o resto deles apontavam para outros domínios.
2. Salvando um backup do arquivo de zona. Quando os registros foram perdidos durante a transferência, era muito útil ter um arquivo de zona já pronto com os registros que eu precisava. A única alteração que eu poderia ter feito era fazer uma varredura final do arquivo de zona e compará-lo com a pré-transferência de configuração antiga, pois infelizmente o arquivo de zona não tinha alguns subdomínios.
3. Usando um TTL razoavelmente baixo . Infelizmente, a maioria dos registradores não permite que você tenha um TTL menor que 1/2 hora, mas eu não entendo as pessoas que optam por definir o TTL para algo como uma semana. Eu preferiria que a infraestrutura recebesse muitos acessos de consulta extra do que algum computador em algum lugar apontando para o lugar errado depois de cinco dias.

Answer 1

Verifique seu DNS atual e seu DNS futuro, só para ter certeza ... Eu fiz o que você vai fazer e saber exatamente o que você está passando! Se você estivesse trocando endereços IP, eu recomendaria que você diminuísse o TTL nos registros existentes, mas nessa situação com os nomes e IP permanecendo os mesmos, sua única exposição será se você não configurou os novos registros corretamente ... Ser capaz de prepará-los é uma ótima coisa ... Eu acho que você não terá um problema.

    

Answer 2

Você pode usar os utilitários de linha de comando host / dig / nslookup e o google dns (8.8.8.8/8.8.4.4) como servidor de nomes independente. E, claro, você deve usar servidores de DNS autoritativos do seu domínio.

# host -t ns example.net 8.8.8.8
# host -t mx example.net 8.8.4.4
# host -t txt example.net ns1.example.net

Haverá cache de qualquer maneira, devido ao TTL da sua zona.