Quanto tempo leva a propagação de DNS (e como acelerá-la)
Você alterou um registro DNS (migrou o site para um novo servidor, trocou de provedor de e-mail, apontou o domínio para a Cloudflare) e agora algumas pessoas veem o site novo e outras o antigo. As empresas de hospedagem costumam dizer "aguarde de 24 a 48 horas para a propagação do DNS". A resposta real depende do que você alterou e de um número que você pode controlar: o TTL. Com um pouco de preparação, a alteração de um registro comum leva minutos, não dias.
O que a "propagação" realmente é
Nada é realmente enviado pela internet. Quando você salva um registro, os servidores de nomes autoritativos do seu provedor de DNS passam a retornar o novo valor quase imediatamente. O atraso vem dos caches. Todo resolvedor que consultou seu domínio antes (o DNS do seu provedor de internet, o Google Public DNS, o Cloudflare 1.1.1.1, o roteador do escritório, seu sistema operacional, seu navegador) mantém a resposta antiga até que a cópia em cache expire, e só então pergunta de novo. "Aguardar a propagação" significa, na prática, esperar esses caches expirarem.
TTL: o número que define a espera
Cada registro DNS tem um TTL (time to live, tempo de vida) em segundos. Ele informa aos resolvedores por quanto tempo eles podem guardar a resposta. Um registro com TTL 3600 pode ser servido do cache por até uma hora depois de ser obtido; com TTL 86400, por até um dia.
| TTL | Por quanto tempo uma resposta antiga pode durar | Onde você costuma ver |
|---|---|---|
| 60–300 | 1–5 minutos | Registros preparados para uma migração, balanceamento de carga, registros com proxy da Cloudflare |
| 3600 | Até uma hora | Um padrão comum em registradores e hospedagens |
| 14400–86400 | 4–24 horas | MX, TXT e zonas antigas que ninguém mexeu |
| 172800 | Até 2 dias | Delegação de NS para .com, .net e muitas outras zonas |
O problema: os resolvedores mantêm o TTL antigo, não o novo. Se o registro tinha TTL 86400 e você o reduziu para 300 no mesmo momento em que alterou o IP, um resolvedor que o obteve ontem ainda guarda o valor antigo, com o tempo de vida antigo de 24 horas, até que ele se esgote. Ele só descobre o novo TTL na próxima consulta.
Por que "24–48 horas" é apenas uma regra geral
Esse número vem do pior caso. A delegação de servidores de nomes para TLDs populares, como .com, é publicada com TTL de dois dias, e alguns registros com TTL longo ficam em cache por um dia. Somando resolvedores que impõem seu próprio tempo mínimo de cache ou que servem respostas expiradas quando não conseguem alcançar seus servidores, "até 48 horas" virou a resposta segura para as equipes de suporte. Para uma alteração comum de registro A com TTL entre 300 e 3600 segundos, a maior parte da internet costuma ver o novo valor em alguns minutos até uma hora. Ninguém pode prometer um horário exato para todas as redes, porque alguns resolvedores não seguem os TTLs à risca.
Alteração de registros vs alteração de servidores de nomes
São duas operações diferentes, e elas se propagam de formas diferentes.
- Alterar um registro (A, AAAA, CNAME, MX, TXT) dentro da zona que você já usa: a espera é igual ao TTL antigo desse registro. Você tem controle total.
- Alterar os servidores de nomes (mover o DNS para outro provedor, adicionar um domínio à Cloudflare): você edita os registros NS no registrador, o registrador os repassa ao registro do TLD, e os resolvedores que já conhecem a delegação antiga a mantêm até o TTL dos registros NS na zona pai expirar, até dois dias para .com. Você não controla esse TTL.
A forma segura de alterar os servidores de nomes é deixar a zona idêntica nos dois provedores antes de trocar: copie todos os registros A, AAAA, CNAME, MX e TXT (incluindo SPF, DKIM e strings de verificação do site), troque o NS no registrador e mantenha a zona antiga por pelo menos dois dias. Assim, não importa a qual provedor o resolvedor pergunte: a resposta estará correta. Se o DNSSEC estiver ativado, planeje a alteração do registro DS com as instruções dos dois provedores em mãos: um registro DS que não corresponde às chaves do novo provedor faz o domínio falhar para resolvedores que validam.
Cache negativo: quando o "não encontrado" também fica em cache
Se alguém consultou new.example.com antes de você criá-lo, os resolvedores guardaram em cache a resposta "não existe" (NXDOMAIN). O tempo que eles a mantêm é definido pelo registro SOA da zona: o menor valor entre o TTL do próprio registro SOA e o seu campo minimum. Por isso, crie os registros primeiro e teste depois: consultar um nome "para ver se já funciona" antes de ele existir pode fazer você esperar mais.
Como acelerar: reduza o TTL com antecedência
- Um dia ou mais antes da mudança, reduza o TTL dos registros que você pretende alterar (por exemplo, os registros A e AAAA) para 300 segundos.
- Aguarde o fim do TTL antigo. Verifique se os resolvers públicos não informam mais um TTL acima de 300 para esses registros.
- Faça a alteração. A maioria dos resolvers assume o novo valor em cerca de cinco minutos.
- Mantenha o servidor antigo funcionando por pelo menos um dia. Alguns provedores de internet e redes corporativas ignoram TTLs curtos e continuam enviando visitantes para lá por algum tempo. No caso de e-mail, o servidor antigo deve continuar aceitando mensagens pelo menos durante o TTL antigo do MX: confira os novos registros com a consulta MX.
- Aumente o TTL novamente para 3600 ou mais quando tudo estiver estável, para reduzir a carga de consultas e ganhar resiliência.
Caches locais: limpe-os antes de entrar em pânico
Muitas vezes a internet já está atualizada e só a sua máquina ficou para trás. Limpe os caches entre você e o resolver:
| Onde | Comando ou ação |
|---|---|
| Windows | ipconfig /flushdns no Prompt de Comando executado como administrador |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux com systemd-resolved | resolvectl flush-caches |
| Chrome, Edge | chrome://net-internals/#dns → "Limpar cache do host"; depois #sockets → "Limpar pools de soquetes" |
| Firefox | about:networking#dns → "Limpar cache DNS" |
| Roteador | Reinicie-o; muitos roteadores domésticos mantêm o próprio cache de DNS |
Verifique também o arquivo hosts (C:\Windows\System32\drivers\etc\hosts ou /etc/hosts): uma linha esquecida ali sobrescreve qualquer DNS. E, se o navegador usa o próprio provedor de "DNS seguro", o navegador e a linha de comando podem divergir. O Google Public DNS e o Cloudflare 1.1.1.1 têm páginas web para solicitar a atualização do cache de um nome específico; o cache do seu provedor de internet não pode ser limpo dessa forma, mas você pode configurar seu dispositivo para usar um resolver público por um tempo.
Como verificar a propagação de DNS
Use o verificador de propagação de DNS. Ele consulta um conjunto de resolvers públicos DNS-over-HTTPS e os nameservers autoritativos da sua zona lado a lado. Interprete o resultado assim:
- Os nameservers autoritativos mostram o novo valor e alguns resolvers públicos mostram o antigo: tudo está configurado corretamente; esses resolvers estão aguardando o fim do TTL. O TTL restante em cada linha indica aproximadamente quanto tempo falta.
- Os nameservers autoritativos ainda mostram o valor antigo: a alteração não foi salva, foi feita na zona errada, ou você está editando o DNS em um provedor que o domínio não usa. Verifique os registros NS e os dados do registrador em uma consulta WHOIS.
- Os nameservers autoritativos divergem entre si: a zona está dessincronizada entre eles, um problema do lado do provedor.
Pela linha de comando, dig example.com @8.8.8.8 consulta um resolver público, e dig example.com @ns1.your-dns-provider.com consulta diretamente o seu servidor autoritativo. Para ver todos os registros do domínio de uma vez, use a consulta DNS, e para confirmar para qual IP o site resolve, a consulta de domínio para IP. Os tipos de registro são explicados em como verificar os registros DNS de um domínio, e formas práticas de descobrir o endereço de um site estão em como encontrar o endereço IP de um site.
