Propagação de DNS: quanto tempo demora e como saber se uma alteração já atualizou

Quando você troca o IP de um site, aponta um domínio para outro serviço, altera os servidores de e-mail ou muda os nameservers, é comum surgir a mesma dúvida: quanto tempo demora para o DNS atualizar?

A resposta curta é: depende do cache que ainda existe entre a configuração autoritativa e quem está fazendo a consulta. Em alguns casos, a nova resposta aparece quase imediatamente. Em outros, usuários diferentes continuam vendo valores antigos por algumas horas.

É por isso que duas pessoas podem abrir o mesmo domínio no mesmo momento e obter resultados diferentes sem que nenhuma delas esteja necessariamente com um problema no computador.

Este guia explica o que realmente acontece durante a chamada “propagação de DNS”, como o TTL interfere, quais registros você deve verificar e como distinguir uma atualização ainda em andamento de um erro de configuração.

O que significa propagação de DNS

O termo “propagação” dá a impressão de que existe uma mudança sendo empurrada de servidor em servidor até alcançar o mundo inteiro. O DNS não funciona exatamente assim.

Quando alguém consulta um domínio, normalmente a resposta passa por um resolvedor DNS recursivo. Esse resolvedor pode guardar a resposta em cache por um período definido pelo TTL do registro. Enquanto a resposta armazenada ainda é válida, ele não precisa perguntar novamente ao servidor autoritativo.

Quando você muda o registro, o servidor autoritativo pode passar a oferecer o novo valor imediatamente. Porém, resolvedores que já guardaram a resposta antiga podem continuar usando esse cache até ele expirar.

Isso explica por que uma mudança pode estar correta no painel do seu provedor e ainda assim não ser vista por todos.

Quanto tempo o DNS demora para atualizar?

Não existe um prazo universal de 24, 48 ou 72 horas que sirva para toda alteração.

Na prática, mudanças podem começar a aparecer em minutos, mas o tempo observado por cada usuário depende de fatores como:

• TTL configurado antes da alteração;
• cache do resolvedor usado pelo provedor de internet ou pela empresa;
• cache do sistema operacional, navegador ou roteador;
• tipo de registro alterado;
• mudança de nameservers no registrador;
• uso de CDN, proxy ou DNS geográfico;
• existência de respostas negativas em cache.

Se um registro A tinha TTL de 3600 segundos, por exemplo, um resolvedor que acabou de armazenar a resposta antiga pode mantê-la por cerca de uma hora. Outro resolvedor cujo cache já estava perto de expirar pode mostrar o novo IP poucos minutos depois.

Por isso, o momento da alteração não é o único ponto importante. O momento em que cada cache recebeu a resposta anterior também influencia.

O que é TTL e por que ele importa

TTL significa Time to Live. É o tempo, normalmente expresso em segundos, durante o qual uma resposta DNS pode permanecer em cache antes de precisar ser consultada novamente.

Alguns exemplos:

• 300 segundos = 5 minutos;
• 1800 segundos = 30 minutos;
• 3600 segundos = 1 hora;
• 14400 segundos = 4 horas;
• 86400 segundos = 24 horas.

Um TTL menor pode acelerar a transição durante uma migração, mas também aumenta a frequência de consultas ao DNS autoritativo. Um TTL maior reduz consultas repetidas, mas faz respostas antigas permanecerem válidas por mais tempo.

Uma prática útil antes de uma migração importante é reduzir o TTL com antecedência, esperar o TTL antigo vencer e só depois fazer a troca principal. Reduzir o TTL no mesmo instante em que você altera o IP não apaga caches que já foram armazenados com o valor anterior.

Qual registro DNS você deve verificar?

Verificar o tipo errado de registro é uma das razões mais comuns para concluir que “o DNS ainda não propagou”.

A

O registro A aponta um nome para um endereço IPv4. É normalmente o primeiro registro a verificar quando um site mudou de servidor ou IP.

Exemplo:

example.com → 203.0.113.20

AAAA

O AAAA faz o equivalente para IPv6. Um site pode ter o registro A correto e ainda apresentar comportamento inesperado para usuários que chegam por IPv6 se o AAAA estiver antigo.

CNAME

O CNAME cria um alias para outro hostname. É comum em subdomínios, serviços SaaS e CDNs.

Exemplo:

www.example.com → site.provider.example

MX

O MX define os servidores responsáveis por receber e-mail para o domínio. Se você migrou de provedor de e-mail, é esse registro que precisa acompanhar.

TXT

Registros TXT são usados para várias finalidades, incluindo SPF, verificações de propriedade e outras configurações de e-mail e serviços externos.

NS

O registro NS indica os servidores de nomes responsáveis pela zona. Uma troca de nameservers merece atenção especial porque envolve também a delegação feita no domínio pai ou no registrador, não apenas a zona que você edita no painel DNS.

Como saber se uma alteração DNS já atualizou

O melhor método não é ficar atualizando o navegador. O ideal é consultar diretamente o tipo de registro alterado e comparar respostas obtidas por resolvedores diferentes.

Uma verificação de propagação DNS permite observar se diferentes visões já retornam o valor novo, se ainda existe divergência e quais TTLs estão sendo vistos.

1. 1Confirme qual registro você alterou: A, AAAA, CNAME, MX, TXT ou NS.
2. 2Digite somente o domínio ou hostname que realmente recebeu a mudança.
3. 3Compare o valor retornado com o valor novo que deveria estar publicado.
4. 4Observe mais de uma visão de DNS, em vez de confiar em uma única consulta local.
5. 5Confira o TTL e repita a consulta depois de um intervalo coerente com o cache esperado.
6. 6Se os resolvedores concordarem, mas o serviço continuar falhando, investigue a camada seguinte, como HTTP, TLS, CDN ou aplicação.

A ferramenta do ProntoUso compara seis visões: Brasil, Estados Unidos, Europa e Ásia usando visões regionais de DNS, além de Google Public DNS e Cloudflare em consultas globais.

As visões regionais são obtidas com EDNS Client Subnet (ECS). Isso é importante: elas representam respostas DNS sensíveis à localização, mas não significam que exista uma máquina física do ProntoUso executando a consulta dentro de cada país.

Como interpretar o consenso entre resolvedores

Se todas as consultas bem-sucedidas retornam a mesma resposta, existe um forte sinal de que o estado visto pelos resolvedores consultados está consistente.

Se algumas retornam o valor antigo e outras o novo, a mudança pode estar em uma fase normal de transição.

Mas consenso parcial não prova automaticamente propagação incompleta.

Para interpretar corretamente, você precisa conhecer a arquitetura do domínio. Se há balanceamento geográfico, CDN ou respostas condicionadas à origem da consulta, não espere necessariamente um único IP mundial.

Por que meu computador ainda vê o DNS antigo?

Mesmo depois de resolvedores públicos mostrarem o valor novo, seu dispositivo pode continuar chegando ao destino antigo.

Isso pode acontecer por causa de:

• cache DNS do sistema operacional;
• cache do navegador;
• cache do roteador;
• resolvedor DNS da empresa ou da rede;
• VPN;
• proxy;
• entrada manual no arquivo hosts;
• conexão IPv6 usando um registro AAAA que não foi alterado.

Antes de concluir que o servidor está com defeito, teste em outra rede ou compare a resolução local com resolvedores públicos.

Também é importante separar DNS de HTTP. O domínio pode resolver para o IP correto e o servidor responder com erro 404, 500 ou um redirecionamento inesperado. Quando o DNS já está consistente, uma consulta ao status HTTP da URL ajuda a verificar o que a aplicação está devolvendo.

Troquei o DNS e agora aparece erro de certificado

Outra situação comum acontece durante migrações de hospedagem.

O DNS já aponta para o servidor novo, mas o navegador mostra um aviso HTTPS. Nesse caso, esperar mais propagação talvez não resolva: o servidor que recebeu o tráfego pode não ter um certificado válido para aquele hostname.

Você pode conferir separadamente o certificado SSL/TLS apresentado pelo domínio. Se o DNS aponta para o destino esperado, mas o certificado pertence a outro site, está expirado ou não cobre o hostname, o problema já saiu da camada de DNS.

E se a consulta não retornar nenhuma resposta?

“Sem resposta” não significa necessariamente que o domínio inteiro está fora do ar.

Um hostname pode simplesmente não possuir o tipo de registro selecionado. Por exemplo, consultar MX em um subdomínio que nunca teve e-mail pode retornar vazio e isso ser perfeitamente normal.

Também existe diferença entre:

• registro inexistente;
• hostname inexistente;
• resolvedor que não respondeu;
• resposta válida sem o tipo de registro solicitado.

Por isso, vale conferir se você está consultando o hostname exato e o registro correto.

Mudança de nameserver costuma exigir mais atenção

Trocar um registro A dentro da mesma zona e trocar os nameservers do domínio são operações diferentes.

Ao mudar NS no registrador, você altera a delegação do domínio. Durante a transição, é essencial garantir que a zona nova já esteja completa antes de efetivar a troca.

• !Copie todos os registros necessários para a nova zona antes de mudar os nameservers.
• !Confira A, AAAA, CNAME, MX e TXT relevantes.
• !Verifique registros de autenticação de e-mail, como SPF, DKIM e DMARC, quando aplicável.
• !Confirme que o servidor DNS novo responde corretamente antes da alteração.
• !Mantenha a zona antiga disponível durante a janela de transição sempre que possível.
• !Evite fazer várias mudanças independentes ao mesmo tempo se você precisar diagnosticar problemas depois.

Esquecer um MX ou TXT durante uma troca de nameserver pode fazer o site funcionar enquanto o e-mail para de funcionar. Isso costuma parecer “propagação”, mas na realidade é uma zona incompleta.

Posso acelerar a propagação depois que já alterei?

Até certo ponto, não.

Você controla o TTL publicado pela sua zona, mas não consegue obrigar todos os caches existentes a esquecer imediatamente uma resposta que receberam anteriormente.

Depois da mudança, as ações mais úteis são:

1. confirmar que o servidor autoritativo já publica o valor correto;
2. acompanhar resolvedores diferentes;
3. evitar alterar o registro repetidamente enquanto os caches estão expirando;
4. testar a aplicação no novo destino;
5. esperar o período compatível com o TTL anterior.

Ficar mudando o IP de volta e para frente pode tornar a análise ainda mais difícil porque diferentes caches passam a armazenar estados de momentos distintos.

O DNS já atualizou, mas o site ainda não funciona

Quando as respostas DNS estão consistentes, o diagnóstico deve avançar para outras camadas.

A sequência costuma ser:

DNS → conexão → TLS/HTTPS → HTTP → aplicação

Se o domínio aponta para o IP correto, verifique se o servidor está ouvindo nas portas esperadas, se o certificado é válido e qual resposta HTTP está sendo devolvida.

Em migrações com proxy reverso ou CDN, também confira se o hostname foi cadastrado no serviço novo e se a origem está configurada corretamente.

Quanto tempo devo esperar antes de investigar um erro?

A melhor referência é o TTL anterior à mudança, não um número genérico encontrado na internet.

Se o TTL era 300 segundos e, horas depois, resolvedores independentes continuam retornando uma resposta antiga que não deveria existir, vale investigar.

Se o TTL era 86400 segundos, encontrar caches antigos durante parte do dia pode ser esperado.

Para troca de nameservers, considere também TTLs da delegação e o comportamento do registrador e dos resolvedores envolvidos.

Em vez de perguntar apenas “já passaram 24 horas?”, pergunte:

• o autoritativo responde com o valor novo?
• quais resolvedores ainda retornam o valor antigo?
• o TTL observado faz sentido?
• existe CDN ou GeoDNS?
• o registro correto está sendo consultado?
• a falha atual realmente é DNS?

Erros comuns durante uma alteração de DNS

Os problemas mais frequentes não são causados pelo tempo.

Entre eles estão:

• editar a zona no provedor errado;
• alterar www mas esquecer o domínio raiz, ou o contrário;
• atualizar A e esquecer AAAA;
• copiar um IP incorreto;
• criar CNAME onde outro registro conflitante já existe;
• migrar e-mail sem copiar MX e TXT;
• trocar NS antes de preparar a zona nova;
• confundir erro HTTP com problema de DNS;
• interpretar IPs diferentes de uma CDN como falha.

Uma consulta de propagação é mais útil quando você já sabe qual valor deveria aparecer.

Perguntas frequentes

DNS sempre demora 24 ou 48 horas para propagar?

Não. Essa é uma simplificação. Algumas mudanças aparecem em minutos, enquanto outras ficam visíveis de forma desigual por horas. TTL, caches existentes e o tipo de alteração importam mais do que uma regra fixa.

Limpar o cache DNS do meu computador atualiza a internet inteira?

Não. Isso afeta apenas o cache local. Outros dispositivos e resolvedores continuam com seus próprios caches.

Se Google e Cloudflare já mostram o valor novo, acabou a propagação?

É um bom sinal, mas não uma garantia absoluta para todos os usuários. Outros resolvedores podem ter caches diferentes. Além disso, GeoDNS e CDNs podem retornar respostas diferentes por design.

Um TTL baixo garante atualização imediata?

Não. Ele reduz o tempo durante o qual novas respostas podem ficar armazenadas, mas não remove caches criados anteriormente com um TTL maior.

Por que o IP muda dependendo da região?

CDNs, balanceamento global e GeoDNS podem responder com destinos diferentes conforme a origem da consulta. Isso pode melhorar latência e disponibilidade e não significa necessariamente erro.

Preciso verificar A e AAAA?

Se o domínio publica os dois, sim. Usuários com conectividade IPv6 podem chegar por AAAA mesmo quando o A está correto.

Em resumo

Propagação de DNS é menos sobre “esperar a internet atualizar” e mais sobre entender cache, TTL e respostas obtidas por resolvedores diferentes.

Antes de esperar horas sem saber o que está acontecendo, identifique o registro alterado, confira o valor autoritativo e compare várias visões DNS. Se os resultados já estiverem consistentes, passe para a próxima camada do diagnóstico.

Essa separação evita um erro muito comum em migrações: continuar culpando o DNS quando o problema real já está no certificado, no servidor web, na CDN ou na própria aplicação.