Você atualizou um registro A. Seu novo servidor está em execução. Você navega até o seu domínio – e ainda vê o site antigo. Ou alguém em outro país vê o novo site, mas você não. Ou ambos estão acontecendo simultaneamente para usuários diferentes.

Esta é a propagação de DNS. Não é um bug e não é o seu registrador que está lento. Aqui está exatamente o que está acontecendo e como gerenciar isso.

O que é propagação de DNS?

DNS (Domain Name System) é um banco de dados distribuído globalmente que mapeia nomes de domínio para endereços IP. Não é um único servidor — é uma hierarquia de milhares de resolvedores, cada um armazenando respostas em cache por um período de tempo.

Ao atualizar um registro DNS, você está alterando os dados do seu servidor de nomes oficial — aquele que seu registrador ou provedor de DNS controla. Mas o resto da Internet não consulta diretamente o seu servidor oficial. Eles perguntam aos seus resolvedor recursivo local (geralmente executado pelo seu ISP ou por um serviço DNS público como 1.1.1.1 ou 8.8.8.8), que possui sua própria cópia em cache do seu registro.

Propagação é o processo em que a cópia em cache expira e é substituída pelo seu novo registro.

A cadeia completa do resolvedor de DNS

Compreensão por que a propagação leva tempo requer a compreensão de como uma consulta DNS realmente funciona:

Diagrama da cadeia do resolvedor DNS mostrando como uma consulta viaja do dispositivo através do resolvedor ISP, servidor raiz, servidor TLD até o servidor de nomes autoritativo
A cadeia completa de pesquisa de DNS. As etapas 2 a 4 geralmente são ignoradas porque o resolvedor recursivo já tem uma resposta em cache – e é exatamente por isso que a propagação leva tempo.

Passo 1 — Seu navegador verifica seu cache local. Os navegadores modernos armazenam em cache os resultados do DNS independentemente do sistema operacional. O Chrome armazena em cache por 60 segundos; Firefox até o valor TTL. chrome://net-internals/#dns mostra o cache atual do Chrome.

Etapa 2 — O resolvedor de stub do sistema operacional verifica seu cache. Windows, macOS e Linux mantêm um cache DNS local (limpo com ipconfig /flushdns, dscacheutil -flushcacheou resolvectl flush-caches respectivamente).

Passo 3 — Seu resolvedor recursivo é consultado. Este é normalmente o resolvedor do seu ISP, 1.1.1.1, 8.8.8.8ou um servidor DNS corporativo. Possui cache próprio, separado do seu, compartilhado por todos os seus usuários. Se 10.000 pessoas usarem o mesmo resolvedor de ISP, uma resposta em cache atenderá a todas elas.

Etapa 4 — O resolvedor recursivo percorre a hierarquia (se o cache estiver vazio). Ele solicita um servidor de nomes raiz para o TLD, o servidor TLD para o servidor de nomes autoritativo e, em seguida, o servidor autoritativo para o seu registro. Ele armazena em cache a resposta com o TTL que você especificou.

A propagação é lenta porque: a etapa 4 só é executada quando o cache do resolvedor expirar. Até então, ele serve a antiga resposta armazenada em cache — independentemente do que você alterou no servidor oficial.

TTL: o número que controla tudo

TTL (Time To Live) é um valor que você define em cada registro DNS, medido em segundos. Ele informa aos resolvedores quanto tempo armazenar em cache seu registro antes de consultar novamente o servidor autoritativo.

Valores TTL comuns:

TTL Segundos Uso típico
1 minuto 60 Migrações ativas, testes
5 minutos 300 Pré-migração (definida 24h antes)
15 minutos 900 Registros alterados com frequência
1 hora 3600 Padrão para a maioria dos registros
4 horas 14400 Registros estáveis
24 horas 86400 Padrão para muitos provedores
48 horas 172800 Registros de servidor de nomes (NS)

O TTL que você define determina o máximo janela de propagação. Mas há um problema.

Gráfico mostrando o tempo de propagação do DNS versus valor TTL com cenários melhores, típicos e piores
O melhor caso reflete resolvedores que respeitam exatamente o TTL. Pior caso: alguns resolvedores de ISP armazenam em cache muito além do TTL declarado, especialmente para TTLs curtos – tratando qualquer coisa abaixo de 5 minutos como “5 minutos” para reduzir a carga.

O segredo sujo sobre o TTL: muitos ISPs ignoram valores baixos de TTL. Um resolvedor que atende milhões de usuários não pode se dar ao luxo de fazer novas consultas a cada 60 segundos para domínios de alto tráfego. Alguns impõem um tempo mínimo de cache de 5 minutos, independentemente do que você declarar. Isso significa que TTLs muito baixos (60–300 segundos) se comportam mais como TTLs de 5 minutos na prática para uma parte dos resolvedores.

Um TTL de 24 horas significa que alguns usuários poderão ver seu registro antigo por 24 horas inteiras após você fazer uma alteração, mesmo que você o tenha alterado imediatamente após a expiração de um TTL anterior.

Quanto tempo realmente leva a propagação do DNS?

Gráfico de linha do tempo estilo Gantt mostrando a propagação do DNS para diferentes regiões do mundo após uma alteração no registro DNS
Cronograma de propagação regional para um registro com TTL de 1 hora. Os resolvedores locais são atualizados mais rapidamente; ISPs discrepantes que ignoram o TTL podem atrasar horas. Isso explica por que alguns usuários veem seu novo site enquanto outros veem o antigo.

Com um TTL padrão de 1 hora, aqui está o que esperar:

  • Seu dispositivo local: quase instantaneamente após limpar o cache
  • Resolvedores da mesma cidade: 5–30 minutos (consultas do resolvedor são autoritativas quando seu cache expira)
  • DNS público principal (8.8.8.8, 1.1.1.1): normalmente 10–60 minutos
  • Propagação mundial: 1–4 horas para a maioria dos usuários
  • ISPs lentos/atípicos: até 8–12 horas

O valor de “até 48 horas” que você vê em todos os lugares é tecnicamente possível, mas cada vez mais raro para registros A e CNAME com TTLs normais. É mais preciso para alterações de registro NS (servidor de nomes), que possuem TTLs inerentes mais longos e se propagam através da camada raiz/TLD.

Por que 48 horas especificamente? Os registros NS geralmente têm TTLs definidos pelo registro (não por você), geralmente de 24 a 48 horas. Ao alterar seus servidores de nomes em seu registrador, você está aguardando a atualização do registro de TLD – e essa atualização se propaga através de servidores raiz em todo o mundo. Esse caminho leva mais tempo do que uma simples alteração de registro em um servidor de nomes fixo.

A abordagem profissional: pré-reduza seu TTL

O maior erro que as pessoas cometem nas migrações de DNS: alterar os registros sem primeiro diminuir o TTL.

O processo certo para migrações planejadas:

  1. 48 horas antes da migração: Reduza o TTL para 300 segundos (5 minutos) em todos os registros que você planeja alterar
  2. Aguarde o TTL atual completo antes da janela de migração (dê tempo aos resolvedores para pegar o novo TTL curto)
  3. Faça alterações no seu registro — a propagação agora leva no máximo 5 minutos em vez de 24 horas
  4. Depois que a migração estiver estável: aumentar o TTL de volta para 3600 ou superior

Esta é a diferença entre uma janela de propagação de 5 minutos e uma de 24 horas. Todo profissional de DNS faz isso. A maioria dos iniciantes aprende da maneira mais difícil.

Como verificar a propagação do DNS agora mesmo

O caminho mais rápido: use nosso Verificador de propagação de DNS — consulta seu domínio de múltiplas localizações geográficas simultaneamente e mostra se cada região está retornando seu registro antigo ou novo.

O que você procura:

  • IPs verdes/correspondentes: essas regiões veem seu novo recorde
  • IP antigo ainda aparecendo: esses resolvedores ainda não expiraram o cache
  • Resultados mistos: normal durante a propagação — algumas regiões veem o novo, outras o antigo

Verifique via linha de comando se quiser verificar a resposta oficial diretamente (ignorando qualquer cache):

Comando 
# Query a specific DNS server directly (bypasses your local cache)
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# On Linux/macOS — dig gives more detail
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# Check the TTL of your current record
dig example.com | grep -i ttl

# Query the authoritative nameserver directly (no cache)
dig example.com @ns1.yourprovider.com

Se dig @ns1.yourprovider.com mostra seu novo recorde, mas dig @8.8.8.8 ainda mostra o antigo, sua alteração está correta — você está apenas esperando o cache do resolvedor recursivo expirar.

Limpe seu cache DNS local para parar de ver dados obsoletos em sua própria máquina:

Comando 
# Windows
ipconfig /flushdns

# macOS (Sequoia / Sonoma)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome browser cache only
# Navigate to: chrome://net-internals/#dns → click "Clear host cache"

Nota: liberar seu cache local não ajuda se o resolvedor do seu ISP ainda tiver a resposta antiga armazenada em cache. Seu dispositivo irá apenas consultar novamente o resolvedor do seu ISP e obter a resposta obsoleta novamente.

Cenários comuns de propagação de DNS

Cenário 1: Migração do site para um novo servidor

Você está mudando do host antigo para o novo host. Registro A antigo: 203.0.113.10. Novo: 198.51.100.20.

O que acontece durante a propagação: usuários com registros antigos em cache chegam ao servidor antigo. Os usuários cujos resolvedores foram atualizados veem o novo servidor. Ambos os servidores precisam estar em execução e servindo o mesmo conteúdo até que a propagação seja concluída. Se você desligar o servidor antigo muito cedo, os usuários com cache desatualizado receberão erros.

Mitigação: manter o servidor antigo ativo por pelo menos um TTL completo após a mudança. Se o TTL original fosse de 24 horas, mantenha o servidor antigo ativo 24 horas após a alteração.

Cenário 2: Migração do provedor de e-mail (registro MX)

As alterações no registro MX afetam o local onde os e-mails recebidos são entregues. Os e-mails enviados durante a propagação podem chegar ao servidor de e-mail antigo ou novo, dependendo de qual registro MX o servidor de envio resolveu.

Risco: e-mails entregues ao servidor antigo depois que você parou de monitorá-lo. Correção: configurar o servidor de e-mail antigo para encaminhar para o novo por uma semana após a migração ou manter as caixas de correio antigas acessíveis durante a janela TTL.

Cenário 3: CDN ou transição do balanceador de carga (alteração de CNAME)

Os registros CNAME que apontam para um CDN ou balanceador de carga normalmente se propagam mais rápido que os registros A — o próprio CNAME armazena em cache, mas o IP subjacente que o CDN retorna pode mudar rapidamente sem afetar a propagação do seu registro.

Cuidado com: Achatamento CNAME. Alguns provedores de DNS "nivelam" os registros CNAME no ápice da zona (substituindo o CNAME pelo registro A para o qual ele resolve). Isso pode causar um comportamento inesperado durante as migrações se o provedor armazenar em cache o IP nivelado.

Cenário 4: Alteração do servidor de nomes (registro NS)

O tipo de propagação mais lento. Os registros do servidor de nomes são armazenados no nível de registro do TLD (.com, .net, etc.) com TTLs definidos pelo registro, normalmente de 24 a 48 horas. Você não controla esse TTL.

Quando você altera os servidores de nomes no seu registrador:

  1. Seu registrador notifica o registro de TLD
  2. Registro atualiza a delegação
  3. A atualização do registro se propaga através de servidores de nomes raiz em todo o mundo

Espere de 12 a 48 horas para propagação completa. Não há truque de pré-redução de TTL que ajude aqui.

Lista de verificação para solução de problemas

✅ Se a sua alteração de DNS não estiver se propagando

1. Confirme se o novo registro está correto no <strong>servidor autoritativo</strong>: <code>dig example.com @ns1.yourprovider.com</code><br> 2. Verifique o que vários resolvedores públicos veem: <a href="/dns-propagation.php">Ferramenta de propagação de DNS →</a><br> 3. Limpe seu cache local (comandos acima) — você pode estar apenas vendo seu próprio cache obsoleto cache<br> 4. Verifique seu TTL: <code>dig example.com | grep TTL</code> — se for 86400, você está esperando até 24h<br> 5. Se autoritativo mostrar correto, mas os resolvedores não: aguarde a expiração do TTL — não há mais nada a fazer<br> 6. Se autoritativo mostrar registro errado: você fez a alteração no provedor errado ou ela não foi salva

Propagação de DNS versus replicação de DNS: a diferença

Muitas vezes são confundidos. Eles estão relacionados, mas distintos:

Propagação DNS = aguardando a expiração dos caches do resolvedor recursivo e nova consulta. Este é o atraso que você experimenta como usuário. Você não pode forçá-lo. Você só pode reduzi-lo diminuindo previamente o TTL.

Replicação DNS = sincronização entre vários servidores de nomes autorizados para a mesma zona (por exemplo, ns1.provider.com e ns2.provider.com). A maioria dos provedores de DNS replica em segundos. Se você fizer uma alteração e ela não aparecer nos servidores de nomes do seu provedor em 5 minutos, isso é um problema do lado do provedor – entre em contato com o suporte.

Ferramentas