O atraso na propagação do DNS é a lacuna entre alterar um registro e cada visitante realmente ver o novo valor, e essa lacuna pode variar de cinco minutos a dois dias inteiros. Se você acabou de migrar hosts, trocou de provedor de e-mail ou apontou seu domínio para novos nameservers, você quer uma resposta direta sobre o que acelera isso e o que você simplesmente não pode tocar. Uma configuração decide a maior parte da espera: o TTL. Tudo depois disso, comportamento do resolvedor, cache do ISP, tempo de registro, fica fora do seu controle, não importa quantas vezes você atualize a página.
O que causa atrasos na propagação de DNS
A propagação de DNS não é um evento único acontecendo em todos os lugares ao mesmo tempo. Como os dados de DNS são armazenados em cache em várias camadas para velocidade, cada alteração precisa percorrer milhares de resolvedores recursivos, servidores ISP e dispositivos de usuários finais antes de chegar a todos. Cada resolvedor, do seu roteador doméstico ao seu ISP, armazena uma resposta DNS por um período definido e continua servindo essa resposta armazenada em vez de perguntar ao servidor autoritativo novamente. Esse período armazenado tem um nome.
TTL, time to live (tempo de vida), é um número em segundos anexado a cada registro DNS que informa aos resolvedores recursivos por quanto tempo eles podem reutilizar a resposta em cache antes de verificar com o servidor de nomes autoritativo novamente. Um registro definido com um TTL de 3600 pode ser mantido por um resolvedor por uma hora; um definido com 86400 pode ser mantido por um dia inteiro. Esse único número é a razão pela qual a mesma alteração pode parecer instantânea para um visitante e invisível para outro por horas.
Há uma complicação até mesmo aqui. Alguns resolvedores simplesmente ignoram um TTL baixo, e certos resolvedores de ISP impõem seu próprio piso mínimo de cache, comumente 300 segundos, independentemente do que você publique. Quando um dispositivo consulta seu domínio, ele pede a um servidor DNS de cache a resposta, esse servidor armazena a resposta pelo tempo que o TTL diz, e durante essa janela ele não voltará para verificar atualizações. Você não pode forçar esse servidor a verificar antes.
Reduzir o TTL antes de uma migração: a única alavanca que você controla
O TTL é definido com antecedência, o que significa que é a única parte deste processo que você realmente consegue planejar. Uma redução em etapas funciona melhor do que uma queda única no dia da migração. Um cronograma amplamente usado parece com isto:
Sete dias antes da mudança, audite o TTL em cada registro crítico (A, MX, CNAME e similares) e limite qualquer coisa maior a 24 horas. Três dias antes, reduza esse valor para 3600 segundos, uma hora. Entre 24 e 48 horas antes da transição, reduza novamente para 300 segundos, cinco minutos, o que proporciona a propagação realista mais rápida durante a troca real.
A espera importa tanto quanto o número. O TTL antigo e mais longo precisa expirar dos caches primeiro antes que o novo, mais curto, entre em vigor em qualquer lugar, então o aviso prévio não é opcional. Reduzir o TTL uma hora antes da transição é tarde demais para ajudar. Faça a alteração real apenas quando esse TTL baixo tiver tido tempo de se espalhar.
O e-mail merece seu próprio item de linha, já que um registro MX quebrado significa mensagens devolvidas, não um carregamento lento de página. Reduza o TTL nos registros MX 48 horas antes da migração para dar tempo suficiente para a propagação. Confirme se o novo servidor de e-mail está realmente funcionando antes de tocar em qualquer registro DNS apontando para ele. Alterne os registros MX durante uma janela de tráfego genuinamente calma, normalmente durante a noite ou em um fim de semana.
Uma vez que o novo servidor esteja estável, desfaça a configuração temporária. Aumente o TTL de volta para 3600 segundos ou mais assim que tudo estiver confirmado como funcionando, já que um TTL mais longo tem melhor desempenho no dia a dia e o valor curto só é útil próximo à mudança em si. Deixá-lo curto permanentemente adiciona carga e dependência aos seus servidores DNS autoritativos sem nenhum benefício contínuo.
O que as pessoas entendem errado sobre a propagação de DNS
A palavra em si causa a maior parte da confusão. Nada está sendo realmente "empurrado" (pushed) pela internet; os caches dos resolvedores simplesmente expiram com base no TTL que o administrador da zona definiu, e nenhum mecanismo transmite sua alteração para lugar nenhum. A única maneira confiável de confirmar que uma alteração está ativa é verificá-la em uma ferramenta de múltiplos resolvedores, resolvedor por resolvedor, em vez de confiar no seu próprio navegador.
O número de "24 a 48 horas" é tratado como uma lei da física, e não é uma para edições comuns de registros. Esse número remonta aos primeiros dias do DNS comercial, quando os registradores rotineiramente impunham TTLs de 24 horas e alguns resolvedores de ISP adicionavam seu próprio atraso por cima. Com um TTL moderno de 300 segundos definido com bastante antecedência, a maioria das alterações de registro é limpa em minutos, não dias.
Mudanças de nameserver são a verdadeira exceção, e o TTL não ajuda aqui da mesma forma que ajuda para registros comuns. Alterar nameservers adiciona uma camada extra de propagação no próprio registro, e as mudanças de registros de nameserver podem levar até 48 horas porque os registros atualizam seus arquivos de zona em seu próprio cronograma, não no seu. Esse atraso existe porque os registros de nameserver vêm dos nameservers raiz, que comumente distribuem um TTL de dois dias inteiros, 172,800 segundos, fazendo com que resolvedores em toda parte mantenham a antiga delegação por tanto tempo.
Os ISPs adicionam uma variável adicional que você não pode auditar de sua própria mesa. Alguns provedores ignoram completamente as configurações de TTL publicadas e só atualizam seus próprios registros em cache a cada dois ou três dias. Se uma alteração parece concluída em todos os verificadores públicos, mas um visitante ainda acessa o servidor antigo, o resolvedor do ISP dele é geralmente a razão, e não a sua configuração.
O que isso significa na prática
Antes de tocar em qualquer coisa, liste cada registro vinculado ao serviço que você está movendo: A, AAAA, CNAME, MX e quaisquer registros TXT para SPF ou DMARC. Observe o TTL atual em cada um, porque esse número é seu cronograma real, não um palpite. Quarenta e oito horas antes da migração, reduza o TTL nos registros A, AAAA e CNAME que você pretende alterar para 300 segundos. Deixe os registros que você não está tocando em paz.
Altere o endereço IP e os nameservers como eventos separados em vez de ao mesmo tempo, já que combiná-los torna muito mais difícil saber qual camada ainda está obsoleta. Mantenha o servidor ou a caixa de correio antiga funcionando durante toda a janela do TTL antigo para que qualquer pessoa que ainda esteja em uma resposta em cache não dê com a cara na parede. Esse hábito simples elimina a maior parte do que as pessoas chamam de interrupção de migração.
Verifique o status com uma ferramenta criada para isso, não com seu próprio navegador. A rede de resolvedores públicos do Google, 8.8.8.8, é uma das maiores do mundo e é geralmente compatível com TTL, o que a torna um ponto de referência confiável. Se sua própria conexão ainda mostrar a resposta antiga após o término da janela TTL, reiniciar o roteador ou alternar para um resolvedor público como o Google Public DNS muitas vezes captará o estado do cache atualizado mais rapidamente do que esperar pelo seu provedor de serviços de internet (ISP).
Uma vez que a mudança esteja confirmada como estável entre os resolvedores, aumente o TTL de volta para um valor de produção e siga em frente. Todo o processo recompensa a paciência no estágio de configuração, não a urgência no dia em si. Uma migração planejada com 48 horas de antecedência com um TTL de 300 segundos quase sempre supera uma feita às pressas no último minuto.
