O que fazer quando as mudanças de DNS não surtem efeito

Uma mudança de DNS que parece não ter efeito é uma das maiores fontes de frustração no trabalho diário com infraestrutura, principalmente porque o sistema por trás (cache distribuído com expiração por registro) fica invisível até você ir procurá-lo de propósito.

Siga estes passos antes de presumir que algo quebrou

1. Confirme que a mudança foi realmente salva no lado autoritativo: consulte diretamente os servidores de nomes autoritativos do próprio domínio, em vez de um resolvedor público genérico, para descartar um salvamento que falhou em silêncio ou que ainda não sincronizou na infraestrutura do próprio provedor.
2. Verifique o TTL anterior do registro: se estava definido, digamos, em 86400 segundos (24 horas), um resolvedor que guardou a resposta antiga em cache poucos minutos antes da sua mudança não vai perguntar de novo por até um dia inteiro.
3. Descarte um cache de DNS no nível do navegador ou do sistema operacional: eles ficam ainda mais perto de você do que o resolvedor configurado e podem guardar uma resposta de forma independente dele.
4. Verifique se você alterou o registro que acha que alterou: um erro surpreendentemente comum é atualizar por engano uma zona de DNS de homologação ou de não produção.
5. Verifique a partir de mais de um ponto de observação: um único resolvedor mostrando a resposta antiga não diz se a mudança já se propagou em todos os outros lugares.

Uma causa menos óbvia: um servidor de nomes secundário (ou “escravo”) atrasado

Configurações de DNS maiores costumam ter um servidor de nomes primário (ou “mestre”), onde as alterações são de fato feitas, e um ou mais servidores de nomes secundários (“escravos”), que copiam a zona dele periodicamente por meio de uma transferência de zona. Se um secundário ainda não recebeu a transferência mais recente (por causa de um cronograma de transferência mal configurado, de um problema de rede entre o primário e o secundário, ou simplesmente porque o intervalo de transferência ainda não decorreu), os resolvedores que por acaso consultarem esse secundário específico continuarão recebendo a resposta antiga, mesmo que o primário esteja totalmente atualizado e o cache baseado em TTL de todos os resolvedores já tenha expirado. Essa causa é menos comum do que o simples cache, mas vale descartá-la especificamente quando servidores de nomes autoritativos diferentes do mesmo domínio discordam entre si, e não apenas quando os resolvedores públicos discordam.

Planejar com antecedência evita quase tudo isso

Em uma mudança planejada (uma migração, uma troca de provedor, uma virada), reduzir o TTL um ou dois dias antes é a ação de maior alavancagem que você pode tomar. Ela custa um pequeno volume extra de consultas em troca de a mudança acabar se propagando em minutos, em vez de potencialmente um dia inteiro. Defina o valor, espere a janela do TTL antigo passar por completo, faça a mudança e depois volte o TTL para o valor original quando confirmar que tudo está certo.

Limpando o seu cache local, quando ele realmente é o culpado

Se os servidores de nomes autoritativos e todos os resolvedores públicos que você verificou já concordam com a nova resposta, mas uma máquina específica ainda mostra a antiga, o cache local dessa própria máquina é o suspeito que resta.

Vale verificar esses itens só depois de confirmar que o lado autoritativo já está correto: limpar um cache local quando o registro real ainda não foi atualizado apenas traz uma cópia nova da mesma resposta antiga e parece idêntico a uma limpeza que falhou.