Como verificar se uma migração de DNS deu certo

Migrar o DNS (trocar de provedor, adotar uma nova configuração de servidores de nomes ou reestruturar um grande conjunto de registros) traz mais risco do que a maioria das mudanças de infraestrutura, justamente porque um erro não falha de forma barulhenta. Um registro quebrado simplesmente para de resolver sem ninguém notar, ou resolve para a coisa errada, e o primeiro sinal costuma ser um chamado de suporte, e não um alerta.

Antes da migração

• Exporte todos os registros existentes do provedor atual: um arquivo de zona completo ou equivalente, e não só os que você se lembra de ter configurado.
• Reduza os TTLs dos registros que vão mudar, com pelo menos um ciclo completo de TTL de antecedência.
• Anote os valores atuais de tudo: A/AAAA, CNAME, MX, TXT (incluindo SPF/DKIM/DMARC) e quaisquer tipos de registro menos comuns em uso.

Depois da migração

1. Consulte diretamente os novos servidores de nomes autoritativos para cada registro migrado e compare cada resposta com a sua exportação anterior à migração.
2. Verifique A e AAAA de forma independente para cada nome de host que tinha qualquer um dos dois: é fácil migrar uma família de endereços e esquecer a outra.
3. Verifique especificamente o MX e os registros de autenticação de e-mail relacionados: falhas de e-mail causadas por uma migração de DNS são desproporcionalmente comuns e desproporcionalmente prejudiciais.
4. Verifique de novo a partir de mais de um resolvedor e, de preferência, de mais de uma localização de rede antes de declarar a migração concluída.
5. Espere passar a janela do TTL antigo e confira de novo: um resultado limpo logo após a virada não garante que todos os resolvedores do mundo com cache já tenham se atualizado.

Uma consulta em lote que cubra a lista completa de nomes de host, executada uma vez logo após a virada e de novo depois que a janela do TTL antigo passar, transforma isso de uma verificação manual registro a registro em uma única etapa repetível, e ainda gera um registro exportável do que exatamente foi verificado e quando.

Não desmonte o lado antigo cedo demais

O arrependimento mais comum após uma migração não é um registro esquecido, e sim a conta ou os servidores de nomes do provedor antigo serem cancelados ou desativados no mesmo dia em que os novos entram no ar. Como uma fração dos resolvedores do mundo ainda trabalha com respostas em cache que apontam para a configuração antiga até o TTL expirar, manter o provedor anterior ativo (mesmo que nada novo aponte para ele) por pelo menos uma janela completa do TTL antigo após a virada é um seguro barato. Se for preciso fazer um rollback rápido, ter o lado antigo ainda respondendo é a diferença entre devolver os servidores de nomes em minutos e reconstruir um arquivo de zona de memória, sob pressão.

Um ensaio pega a maioria dos problemas antes de serem reais

Quando o novo provedor de DNS permite, montar a nova zona completa com antecedência (totalmente configurada, mas ainda sem delegação para ela) e consultá-la diretamente (contornando a delegação normal, seja apontando explicitamente uma ferramenta de teste para os servidores de nomes dela, seja usando o recurso de pré-visualização do próprio provedor) transforma a verificação da migração: em vez de uma correria pós-virada, ela vira uma conferência pré-virada, sem nenhum impacto sobre os usuários se algo estiver errado. Qualquer registro ausente, mal configurado ou simplesmente diferente do pretendido aparece antes que um único resolvedor real o tenha visto, o que é um lugar bem menos estressante para pegar um erro do que depois que a virada já entrou no ar.