Propagação DNS: quanto tempo realmente demora?

Por CaptainDNS
Publicado em 26 de março de 2026

Diagrama mostrando os prazos reais de propagação DNS em função do TTL em diferentes resolvedores públicos

TL;DR

A "propagação DNS" não existe como mecanismo: o DNS não envia nada. São os caches dos resolvedores que expiram conforme o TTL (Time To Live) configurado pelo administrador da zona.
O prazo real depende do TTL do registo modificado: 1 minuto (TTL 60) a 24 horas (TTL 86400). Nenhuma razão técnica justifica um prazo de 48 horas.
Reduzir o TTL para 300 segundos 48 horas antes de uma alteração DNS elimina o mito das "24 a 48 horas". Após a modificação, o novo registo fica visível em todos os lugares em 5 minutos.
Verificar em tempo real com uma ferramenta multi-resolvedores permite confirmar que a alteração está efetiva, resolvedor por resolvedor.

"Aguarde 24 a 48 horas para a propagação DNS." Se já alterou um registo DNS, já leu essa frase. Nas páginas de ajuda do seu registrar, em um ticket de suporte ou em um tutorial encontrado em um mecanismo de busca. É provavelmente o conselho técnico mais repetido na Internet. E também um dos mais enganosos.

O DNS não "propaga" nada. Não existe nenhum mecanismo de difusão no protocolo DNS que envie as alterações para os resolvedores do mundo inteiro. O que existe é um sistema de cache distribuído com um relógio de expiração: o TTL. Quando modifica um registo, os resolvedores que possuem o valor antigo em cache continuam a servir-o até a expiração do TTL. Em seguida, consultam o servidor autoritativo e obtêm o novo valor. É só isso.

O prazo percebido é inteiramente controlável. Se o TTL é de 5 minutos, a alteração fica visível em todos os lugares em 5 minutos. Se é de 24 horas, será preciso aguardar 24 horas. O número "48 horas" não corresponde a nenhum valor de TTL padrão. Ele vem de uma época ultrapassada, a dos primórdios do DNS comercial, quando os registrars impunham TTLs de 86.400 segundos (24 horas) e os resolvedores dos fornecedores de Internet por vezes adicionavam os seus próprios atrasos.

Este artigo vai detalhar o mecanismo real, quantificar os prazos exatos para cada valor de TTL e fornecer um método de migração DNS que torna o prazo previsível e controlado.

Verifique a sua propagação DNS

Testar a propagação DNS Executar um DNS Lookup

O mito das "24 a 48 horas"

De onde vem esse número?

Para entender a origem do mito, é preciso voltar aos anos 2000. Naquela época, registrars como Network Solutions, GoDaddy ou Gandi configuravam TTLs padrão de 86.400 segundos (24 horas) nos registos que geriam. Alguns registos de TLD (como a VeriSign para .com e .net) atualizavam os ficheiros de zona a cada 12 horas. Combinando esses dois fatores, uma alteração de servidor NS podia realmente levar até 36 horas para ficar visível em todos os lugares. Arredondar para "48 horas" permitia cobrir os casos extremos.

O problema é que essa estimativa ficou congelada na documentação enquanto a infraestrutura mudou. Hoje, os registos principais atualizam as suas zonas em poucos minutos. Os registrars modernos oferecem TTLs de 3.600 segundos (1 hora) por predefinição, por vezes 300 segundos. A realidade técnica de 2026 não tem mais nada a ver com a de 2002.

A palavra "propagação" é um equívoco

O termo "propagação" sugere um processo ativo de difusão. Como se uma alteração DNS fosse enviada de servidor em servidor, à maneira de uma atualização de software que se implanta progressivamente. Essa imagem mental é falsa.

O DNS funciona em um modelo pull, não push. Nenhum servidor envia notificação aos resolvedores para informar que "o valor mudou". Cada resolvedor recursivo decide por conta própria quando consulta o servidor autoritativo, em função do TTL do registo que tem em cache.

Veja o que realmente acontece quando um utilizador digita captaindns.com no navegador:

O stub resolver da máquina local verifica o seu cache. Se tem uma resposta válida (TTL não expirado), retorna-a imediatamente.
Se não tem nada em cache, reencaminha a consulta ao resolvedor recursivo configurado (o do fornecedor de Internet, do Google, da Cloudflare, etc.).
O resolvedor recursivo verifica o seu próprio cache. Se tem uma resposta válida, retorna-a.
Se não tem nada ou se o TTL expirou, inicia uma resolução completa: consulta um servidor raiz, depois o servidor TLD (.com), depois o servidor autoritativo do domínio.
O servidor autoritativo retorna a resposta atual (o novo registo, se o modificou) com o TTL configurado.
O resolvedor armazena essa resposta em cache pela duração do TTL e retorna-a ao utilizador.

O "prazo de propagação" nada mais é do que o tempo restante antes da expiração do cache. Se o resolvedor armazenou o registo antigo em cache há 30 minutos com um TTL de 3.600 segundos, serão necessários mais 30 minutos antes que ele consulte novamente o servidor autoritativo.

Diagrama da resolução DNS hierárquica: stub resolver, resolvedor recursivo, servidor raiz, TLD, servidor autoritativo

O TTL: o verdadeiro relógio da propagação

O que é o TTL?

O TTL (Time To Live) é um campo numérico associado a cada registo DNS, expresso em segundos. Ele indica aos resolvedores por quanto tempo podem manter a resposta em cache antes de precisar solicitá-la novamente ao servidor autoritativo.

O TTL é definido pelo administrador da zona DNS, não pelo protocolo. É uma escolha operacional. Cada registo em uma zona pode ter o seu próprio TTL. Pode configurar um TTL de 60 segundos em um registo A que aponta para um serviço de alta disponibilidade, mantendo ao mesmo tempo um TTL de 86.400 segundos em um registo MX que nunca muda.

A RFC 1035 (secção 3.2.1) define o TTL como um inteiro sem sinal de 32 bits, ou seja, um valor máximo teórico de 2.147.483.647 segundos (aproximadamente 68 anos). Na prática, a RFC 2181 (secção 8) recomenda tratar qualquer valor superior a 2.147.483.647 como 0. Os valores comuns vão de 60 a 86.400 segundos.

Para verificar o TTL atual de um registo, use o dig:

dig captaindns.com A +noall +answer

A saída se parece com isto:

captaindns.com.    3600    IN    A    76.76.21.21

O número 3600 é o TTL restante em segundos. Atenção: esse valor decresce a cada segundo. Se executar o comando novamente 10 segundos depois, verá 3590. Quando atinge 0, o resolvedor considera a entrada expirada e consulta novamente o servidor autoritativo.

Para obter o TTL definido pelo servidor autoritativo (e não o TTL restante no cache do resolvedor), consulte diretamente o servidor autoritativo:

dig captaindns.com A @ns1.captaindns.com +noall +answer

Tabela de prazos reais por TTL comum

Esta tabela mostra o prazo máximo entre uma alteração DNS e a sua visibilidade completa em todos os resolvedores, supondo que o resolvedor armazenou o registo antigo em cache logo antes da modificação (pior caso).

TTL (segundos)	Duração legível	Prazo máx. de visibilidade	Uso típico
60	1 minuto	1 minuto	Failover automático, alta disponibilidade, serviços críticos
300	5 minutos	5 minutos	CDN, balanceamento de carga, pré-migração
900	15 minutos	15 minutos	Serviços em nuvem (AWS, GCP, Azure)
1800	30 minutos	30 minutos	Aplicações SaaS
3600	1 hora	1 hora	Padrão comum dos registrars modernos (Cloudflare, Route 53)
14400	4 horas	4 horas	Padrão histórico OVH, Gandi, alguns painéis cPanel
43200	12 horas	12 horas	Registos estáveis raramente modificados
86400	24 horas	24 horas	Registos NS, registos de zona estáveis, padrão histórico

As "24 a 48 horas" do mito correspondem ao pior caso de um TTL de 86.400 combinado com um resolvedor que teria armazenado o valor em cache um segundo antes da modificação. Nesse cenário, o prazo máximo é de 24 horas, não 48. As 48 horas são um arredondamento de precaução sem fundamento técnico.

Porque alguns resolvedores ignoram o TTL?

O protocolo DNS (RFC 1035) exige que os resolvedores respeitem o TTL. Na prática, algumas divergências existem.

TTL mínimo imposto. O Google Public DNS impõe um piso de 30 segundos. Se um servidor autoritativo retorna um TTL de 0 ou 10 segundos, o Google o trata como 30 segundos. Esse comportamento está documentado na sua FAQ técnica. A Cloudflare aplica um piso semelhante. O impacto é desprezível para a maioria dos casos de uso.

TTL máximo imposto. Alguns resolvedores de fornecedores de Internet aplicam um teto de TTL para reduzir a carga nos seus servidores. Um fornecedor que processa milhões de consultas por segundo pode decidir não respeitar um TTL de 60 segundos e tratá-lo como 300 segundos. Esse comportamento é raro, não documentado e contrário às RFCs, mas existe.

Cache negativo. O TTL também se aplica às respostas NXDOMAIN (domínio inexistente) por meio do campo SOA minimum TTL (RFC 2308). Se cria um novo registo para um nome que não existia, o resolvedor pode ter armazenado em cache a resposta "não existe" com o TTL negativo da zona SOA. Esse prazo é frequentemente esquecido durante as migrações.

Para verificar o TTL negativo da sua zona:

dig captaindns.com SOA +noall +answer

captaindns.com.    3600    IN    SOA    ns1.captaindns.com. admin.captaindns.com. 2026032601 7200 900 1209600 300

O último campo (300) é o TTL negativo. As respostas NXDOMAIN serão armazenadas em cache por 300 segundos (5 minutos).

Os resolvedores DNS: todos diferentes em relação ao cache

O cache hierárquico

A resolução DNS atravessa vários níveis de cache antes de atingir o servidor autoritativo. Cada nível pode retornar uma resposta sem ir adiante:

Nível 1: o cache da aplicação. Os navegadores e aplicações mantêm o seu próprio cache DNS. O Chrome, por exemplo, mantém as resoluções por 60 segundos por predefinição. Esse cache é independente do sistema operacional.

Nível 2: o stub resolver (cache do SO). O sistema operacional mantém um cache DNS local. No Windows, o serviço "Cliente DNS" gere esse cache. No macOS, é o mDNSResponder. No Linux com systemd, é o systemd-resolved. Esse cache geralmente respeita o TTL retornado pelo resolvedor recursivo.

Nível 3: o resolvedor recursivo. É o servidor DNS configurado na sua ligação de rede (o do fornecedor de Internet, Google 8.8.8.8, Cloudflare 1.1.1.1, etc.). É ele que realiza a resolução completa consultando a hierarquia DNS e que mantém o cache mais volumoso. O TTL nesse nível determina o prazo percebido de "propagação".

Nível 4: os relays DNS intermediários. Em redes corporativas, um servidor DNS interno (Active Directory, Pi-hole, dnsmasq) pode servir de relay para o resolvedor recursivo. Esse relay adiciona um nível extra de cache, com as suas próprias regras de retenção.

Uma alteração DNS só é plenamente visível para um utilizador quando todos os níveis de cache que ele atravessa expiraram. No pior caso (todos os caches acabaram de ser preenchidos), o prazo é o do TTL mais alto na cadeia. Na prática, os caches de aplicação e do SO têm TTLs curtos (60 segundos ou menos), então o gargalo é quase sempre o resolvedor recursivo.

Porque os resultados variam conforme o resolvedor?

Ao testar a propagação DNS, pode obter resultados diferentes conforme o resolvedor consultado. Isso é normal, e há três razões para isso.

Razão 1: o instante de armazenamento em cache difere. O Google DNS pode ter armazenado o registo antigo em cache há 2 minutos, enquanto a Cloudflare fez isso há 55 minutos. Com um TTL de 3.600 segundos, o Google servirá o valor antigo por mais 58 minutos, enquanto a Cloudflare o servirá por mais 5 minutos. Mesmo TTL, mas desfasamento temporal.

Razão 2: a infraestrutura de cache é distribuída. O Google DNS não é um único servidor. É uma rede de servidores anycast distribuídos em centenas de datacenters. Cada instância mantém o seu próprio cache. Uma consulta de Paris atinge um servidor Google diferente daquele de Tóquio. Os dois podem ter valores de cache diferentes. É por isso que dois utilizadores consultando "8.8.8.8" no mesmo momento podem obter respostas diferentes.

Razão 3: EDNS Client Subnet (ECS). Alguns domínios usam respostas geolocalizadas via EDNS Client Subnet. O servidor autoritativo retorna endereços IP diferentes conforme a localização do cliente. Um utilizador na França obtém o IP do datacenter europeu, um utilizador no Japão obtém o IP do datacenter asiático. Não é um problema de propagação: é o comportamento esperado de um CDN. Mas isso complica o diagnóstico, pois os resolvedores possuem respostas legitimamente diferentes em cache.

Timeline mostrando a expiração do cache em diferentes resolvedores públicos: Google DNS, Cloudflare e Quad9 expiram o cache em momentos diferentes

Para verificar o que cada resolvedor tem em cache, consulte-os diretamente:

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer

Se os três retornam o mesmo IP com TTLs restantes diferentes, é a prova de que a alteração está em andamento e de que os caches expiram em momentos diferentes.

Guia prático: migração DNS sem surpresas

O método a seguir elimina a incerteza de uma migração DNS. Ele baseia-se em um princípio simples: reduzir o TTL antes da alteração para que o cache expire rapidamente após a modificação. É a técnica padrão usada pelos SREs (Site Reliability Engineers) durante migrações de infraestrutura.

Antes da alteração: D-48

Etapa 1: verificar o TTL atual.

Consulte o servidor autoritativo para conhecer o TTL definido (não o TTL restante em um cache):

dig captaindns.com A @ns1.captaindns.com +noall +answer

Se o TTL é de 86.400 segundos (24 horas), será preciso reduzir e aguardar a expiração do cache antigo.

Etapa 2: reduzir o TTL para 300 segundos (5 minutos).

Na interface do seu registrar ou no gestor de zona DNS, modifique o TTL do registo que pretende alterar. Não altere ainda o valor do registo. Apenas o TTL muda.

captaindns.com.    300    IN    A    76.76.21.21

Etapa 3: aguardar a expiração do TTL antigo.

Esta é a etapa crucial. Após reduzir o TTL para 300, deve aguardar que o TTL antigo expire em todos os lugares. Se o TTL antigo era de 86.400 segundos, aguarde 24 horas. Se era de 3.600 segundos, aguarde 1 hora.

Por quê? Porque os resolvedores que possuem o registo em cache com o TTL antigo de 86.400 não verão a sua alteração de TTL enquanto o cache deles não expirar. Assim que o TTL antigo expirar, todos os resolvedores consultarão novamente o servidor autoritativo e obterão o registo com o novo TTL de 300 segundos.

É por isso que é preciso começar 48 horas antes: no pior caso (TTL inicial de 86.400), precisa de 24 horas para a propagação do novo TTL, mais uma margem de segurança.

Verifique o progresso consultando vários resolvedores:

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer

Quando os três retornarem um TTL restante igual ou inferior a 300, o novo TTL está em vigor.

No dia da alteração: D

Etapa 4: realizar a alteração DNS.

Modifique o valor do registo no seu registrar ou fornecedor DNS. Por exemplo, para uma migração de servidor:

captaindns.com.    300    IN    A    185.199.108.153

O TTL permanece em 300 segundos. A alteração ficará visível em todos os resolvedores em no máximo 5 minutos.

Etapa 5: verificar a propagação.

Consulte os principais resolvedores públicos para confirmar que a alteração está efetiva:

dig captaindns.com A @8.8.8.8 +noall +answer
dig captaindns.com A @1.1.1.1 +noall +answer
dig captaindns.com A @9.9.9.9 +noall +answer
dig captaindns.com A @208.67.222.222 +noall +answer

A ferramenta de teste de propagação CaptainDNS realiza essa verificação automaticamente, consultando resolvedores distribuídos em vários continentes.

Etapa 6: validar o serviço.

Verifique se o serviço está a funcionar corretamente no novo endereço. Teste os acessos HTTP/HTTPS, os envios de e-mails, as ligações de API. Não passe para a próxima etapa enquanto tudo não estiver confirmado.

Após a alteração: D+1

Etapa 7: restaurar o TTL.

Assim que a alteração estiver confirmada e o serviço validado, restaure o TTL para um valor padrão. Um TTL de 3.600 segundos (1 hora) é um bom equilíbrio entre reatividade e redução de carga DNS:

captaindns.com.    3600    IN    A    185.199.108.153

Um TTL muito baixo (60 segundos) permanentemente sobrecarrega os servidores autoritativos. Um TTL muito alto (86.400 segundos) torna as migrações futuras mais demoradas. Para registos que raramente mudam (NS, MX), um TTL de 3.600 a 14.400 é razoável.

Etapa 8: monitorizar durante 24 a 48 horas.

Monitorize as métricas do serviço (tempo de resposta, taxa de erros, entregabilidade de e-mail) durante as horas seguintes à migração. Resolvedores com comportamentos fora do padrão podem demorar para atualizar o seu cache. Uma ferramenta de supervisão DNS resiliente permite detetar essas anomalias.

Como acelerar a "propagação"?

Quando a alteração já foi feita e alguns resolvedores ainda servem o valor antigo, existem algumas ações concretas para reduzir o prazo. Nenhuma substitui o método de redução de TTL descrito acima, mas são úteis como complemento.

Limpar o cache DNS local

O cache da sua máquina local pode conter o valor antigo. Limpá-lo força o sistema a consultar novamente o resolvedor recursivo.

Windows (PowerShell como administrador):

ipconfig /flushdns

macOS (Terminal):

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Chrome (barra de endereços):

chrome://net-internals/#dns

Clique em "Clear host cache". O Chrome mantém o seu próprio cache DNS, independente do SO.

Solicitar uma purga aos resolvedores públicos

Alguns resolvedores públicos oferecem uma interface para purgar um registo específico do cache. Não é uma garantia (o registo será armazenado em cache novamente na próxima consulta), mas força uma re-resolução imediata.

Google Public DNS: aceda à página Google Public DNS Flush Cache e introduza o domínio e o tipo de registo a ser purgado.

Cloudflare: aceda à página Cloudflare Purge Cache e introduza o domínio.

Essas ferramentas purgam o cache de um único nó (aquele que processa a sua consulta). Resolvedores como Google e Cloudflare usam anycast: o cache está distribuído em centenas de servidores. Purgar a partir de Paris não purga o cache do servidor que atende os utilizadores de São Paulo.

O que NÃO funciona

Algumas "soluções" circulam em fóruns e páginas de suporte. Elas são ineficazes, ou até contraproducentes.

Reiniciar o router. O cache DNS do router doméstico é frequentemente limitado a algumas dezenas de entradas e expira rapidamente. Mesmo que a reinicialização limpe esse cache, o resolvedor recursivo do fornecedor de Internet (o verdadeiro gargalo) mantém o valor antigo.

Trocar de resolvedor DNS no computador. Passar do Google (8.8.8.8) para a Cloudflare (1.1.1.1) pode dar a impressão de que a alteração foi propagada, pois a Cloudflare pode não ter a mesma entrada em cache que o Google. Mas isso não resolve nada para os outros utilizadores. É um viés de observação, não uma solução.

Esperar "mais um pouco". Se a alteração não está visível após o prazo correspondente ao TTL, esperar mais não resolverá nada. O problema está em outro lugar: TTL negativo em cache, erro na zona DNS, servidor autoritativo mal configurado ou resolvedor que não respeita o TTL. É preciso diagnosticar, não ter paciência.

Casos de uso específicos

Mudança de alojamento (A / AAAA)

É o caso mais frequente: está a migrar um site para um novo servidor. O registo A (IPv4) ou AAAA (IPv6) muda de endereço IP.

O plano padrão funciona perfeitamente aqui. Reduza o TTL 48 horas antes, altere o IP, verifique. A particularidade: se o servidor antigo e o novo estão configurados para responder ao mesmo nome de domínio, os utilizadores que obtêm o IP antigo veem o servidor antigo, e os que obtêm o novo veem o novo. Durante a transição, os dois servidores devem funcionar em paralelo.

Para migrações com alteração simultânea de endereço IPv4 e IPv6, não esqueça de modificar ambos os registos. Um esquecimento no registo AAAA deixa os clientes IPv6 apontando para o servidor antigo.

CNAME e aliases

Os registos CNAME possuem o seu próprio TTL, mas o resolvedor também precisa de resolver o destino do CNAME. O prazo total é o máximo entre o TTL do CNAME e o TTL do registo de destino. Se o seu CNAME tem TTL de 300, mas aponta para um registo A com TTL de 86.400, a alteração do valor A levará até 24 horas, mesmo que o próprio CNAME seja resolvido em 5 minutos.

E-mail: MX, SPF, DKIM, DMARC

Os registos relacionados a e-mail merecem atenção especial, pois as consequências de um erro são mais graves do que para um site web. Um site inacessível por 10 minutos é um inconveniente. E-mails perdidos por 10 minutos podem ter consequências profissionais sérias.

MX (Mail Exchanger). Os registos MX frequentemente têm um TTL alto (3.600 a 86.400). Durante uma migração de fornecedor de e-mail, a redução do TTL é obrigatória. Durante a transição, ambos os servidores MX devem aceitar o correio para o seu domínio. Configure o fornecedor antigo para reencaminhar as mensagens ao novo, se possível.

SPF (registo TXT). A alteração de um registo SPF entra em vigor assim que o TTL do TXT expira. O risco: se adiciona um novo fornecedor de envio (como uma ferramenta de marketing) sem atualizar o SPF, os e-mails dele serão rejeitados pelos servidores que possuem o SPF antigo em cache. Solução: adicione o mecanismo SPF antes de começar a enviar pelo novo fornecedor e aguarde a expiração do TTL.

DKIM (registo TXT em _domainkey). A publicação de uma nova chave pública DKIM segue as mesmas regras de TTL. Atenção durante a rotação de chave: a chave antiga deve permanecer publicada no DNS enquanto e-mails assinados com ela ainda estiverem em trânsito (as filas de e-mail podem reter mensagens por vários dias).

DMARC (registo TXT em _dmarc). Uma alteração de política DMARC (passagem de p=none para p=quarantine, por exemplo) entra em vigor progressivamente, conforme a expiração dos caches. É recomendado passar pelo modo p=quarantine antes de p=reject para limitar falsos positivos durante a transição.

DNSSEC

A ativação ou modificação do DNSSEC adiciona uma camada extra de complexidade. Dois tipos de registos estão envolvidos: os DNSKEY na zona DNS e o registo DS (Delegation Signer) no registrar.

O registo DS é publicado na zona do TLD pai (por exemplo, na zona .com para um domínio .com). A sua atualização depende do registrar e do registo TLD. O prazo frequentemente é mais longo do que para um registo padrão, pois envolve comunicação entre o registrar e o registo.

A regra durante a ativação do DNSSEC: publicar os DNSKEY primeiro, aguardar a propagação completa (pelo menos 2 vezes o TTL), e depois adicionar o registo DS. Se o DS for adicionado antes que os DNSKEY estejam visíveis em todos os lugares, alguns resolvedores validadores retornarão SERVFAIL, tornando o domínio inacessível.

Alteração de servidores NS (delegação)

Alterar os servidores autoritativos (registos NS) é o caso mais delicado. Os registos NS no nível do TLD possuem o seu próprio TTL (frequentemente 48 horas para .com). O resolvedor deve respeitar esse TTL antes de consultar novamente o registo TLD.

O procedimento recomendado:

Reproduzir a zona DNS completa nos novos servidores NS
Reduzir o TTL de todos os registos importantes para 300 segundos
Aguardar a expiração do TTL antigo
Modificar a delegação NS no registrar
Manter os servidores NS antigos ativos por 48 a 72 horas (o tempo necessário para os caches NS expirarem)
Verificar que ambos os conjuntos de servidores NS retornam as mesmas respostas durante todo o período de transição

Diagnóstico: porque minha alteração DNS não funciona?

Quando a alteração ainda não está visível após o prazo previsto, é preciso diagnosticar. Aqui estão as causas mais frequentes, classificadas por probabilidade.

Causa 1: a alteração não foi registada

É a causa mais comum. A interface do registrar exibiu "registado", mas o servidor autoritativo ainda não possui o novo valor. Verifique diretamente:

dig captaindns.com A @ns1.captaindns.com +noall +answer

Se o registo antigo aparece, o problema está no fornecedor DNS, não na propagação.

Causa 2: o cache negativo

Se criou um novo registo (que não existia antes), o resolvedor pode ter uma resposta NXDOMAIN em cache. Verifique o TTL negativo no SOA:

dig captaindns.com SOA +noall +answer

O último campo do SOA é o TTL negativo. Aguarde esse prazo.

Causa 3: o tipo de registo errado

Alterou o registo A, mas o DNS retorna um CNAME que aponta para o registo antigo. Ou modificou um TXT, mas existem dois registos TXT e editou o errado. Verifique solicitando todos os tipos:

dig captaindns.com ANY @ns1.captaindns.com

Causa 4: DNSSEC quebrado

Se o DNSSEC está ativo e a cadeia de confiança está rompida (registo DS não correspondendo mais ao DNSKEY), os resolvedores validadores retornam SERVFAIL em vez da resposta. Teste com e sem validação DNSSEC:

dig captaindns.com A @8.8.8.8 +dnssec
dig captaindns.com A @8.8.8.8 +cd

A flag +cd (Checking Disabled) desativa a validação DNSSEC. Se a consulta funciona com +cd, mas não sem, o problema é o DNSSEC.

Causa 5: relay DNS corporativo com cache agressivo

Em uma rede corporativa, um servidor DNS interno (Active Directory, Pi-hole) pode armazenar as respostas em cache com um TTL superior ao retornado pelo resolvedor recursivo. Entre em contacto com o administrador de rede para limpar o cache do servidor DNS interno.

Compreendendo o papel da zona SOA

O registo SOA (Start of Authority) contém parâmetros que influenciam indiretamente a "propagação". Os seus campos são frequentemente negligenciados durante o planeamento de uma migração.

dig captaindns.com SOA +noall +answer

captaindns.com. 3600 IN SOA ns1.captaindns.com. admin.captaindns.com. (
    2026032601 ; serial
    7200       ; refresh (2 horas)
    900        ; retry (15 minutos)
    1209600    ; expire (14 dias)
    300        ; minimum / negative TTL (5 minutos)
)

Serial: número de versão da zona. Os servidores secundários comparam esse número para detetar alterações. Um serial não incrementado após uma modificação impede a sincronização com os servidores secundários.

Refresh: intervalo no qual os servidores secundários verificam se a zona mudou. Um refresh de 7.200 segundos (2 horas) significa que o servidor secundário pode servir uma zona desatualizada por 2 horas. Esse parâmetro impacta a coerência entre servidores autoritativos, não o cache dos resolvedores recursivos.

Minimum (TTL negativo): o TTL aplicado às respostas NXDOMAIN. Se cria um novo registo, os resolvedores que possuem uma resposta NXDOMAIN em cache deverão aguardar esse prazo. Valor recomendado: 300 segundos (5 minutos).

Os resolvedores públicos e as suas particularidades

Cada resolvedor público possui comportamentos específicos que influenciam a perceção da propagação. Conhecer essas especificidades ajuda no diagnóstico. Um comparativo dos resolvedores DNS públicos permite aprofundar esse assunto.

Google Public DNS (8.8.8.8 / 8.8.4.4)

TTL mínimo: 30 segundos
Interface de purga disponível
Infraestrutura anycast massiva (centenas de PoPs)
Suporta EDNS Client Subnet para respostas geolocalizadas

Cloudflare (1.1.1.1 / 1.0.0.1)

TTL mínimo: 30 segundos
Interface de purga disponível
Arquitetura anycast em mais de 310 datacenters
Não transmite a sub-rede do cliente por predefinição (melhor privacidade)

Quad9 (9.9.9.9 / 149.112.112.112)

Filtragem de malware integrada (pode bloquear certos domínios)
TTL mínimo não documentado publicamente
Sem interface de purga pública
Validação DNSSEC ativada por predefinição

OpenDNS (208.67.222.222 / 208.67.220.220)

Filtragem configurável (categorias de conteúdo)
Cache que pode ser mais persistente do que o TTL em certos casos
Interface de purga via painel de controlo

Resolvedores de fornecedores de Internet

Comportamento variável e frequentemente não documentado
Alguns impõem TTLs mínimo ou máximo
Cache por vezes partilhado entre milhões de assinantes (efeito de mutualização)
Raramente possuem interface de purga

Plano de ação recomendado

Aqui está o procedimento completo, resumido em 5 etapas. Imprima-o ou guarde-o para a sua próxima migração DNS.

Verificar o TTL atual: consulte o servidor autoritativo com dig ou use a ferramenta CaptainDNS para obter o TTL de cada registo da sua zona.
Reduzir o TTL 48 horas antes: reduza para 300 segundos todos os registos que pretende modificar. Não esqueça os registos associados (AAAA se alterar o A, TXT se migrar o e-mail).
Realizar a alteração: modifique os registos DNS no seu registrar ou fornecedor. Verifique imediatamente se o servidor autoritativo retorna o novo valor.
Verificar a propagação: teste a partir de vários resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS). Use uma ferramenta de teste de propagação para uma visão global em todos os continentes.
Restaurar o TTL: assim que a alteração estiver confirmada e o serviço validado, restaure um TTL padrão (3.600 segundos). Mantenha a monitorização por 24 horas.

FAQ

Quanto tempo dura a propagação DNS?

O prazo depende unicamente do TTL (Time To Live) do registo modificado. Com um TTL de 300 segundos, a alteração fica visível em todos os lugares em 5 minutos. Com um TTL de 3.600 segundos, conte no máximo 1 hora. Com um TTL de 86.400 segundos, o prazo máximo é de 24 horas. Não há nenhuma razão técnica para um prazo de 48 horas. O mito das "24 a 48 horas" vem de uma época em que os TTLs padrão eram de 86.400 segundos e os registos de TLD atualizavam as suas zonas a cada 12 horas.

Como acelerar a propagação DNS?

O método mais eficaz é reduzir o TTL para 300 segundos (5 minutos) pelo menos 48 horas antes da alteração prevista. Uma vez que o TTL reduzido esteja propagado, qualquer alteração posterior ficará visível em 5 minutos. Como complemento, pode limpar o cache da sua máquina local (ipconfig /flushdns no Windows, sudo dscacheutil -flushcache no macOS) e usar as interfaces de purga do Google Public DNS e da Cloudflare para forçar uma re-resolução nesses resolvedores específicos.

Porque minha alteração DNS não funciona?

As causas mais frequentes são, por ordem de probabilidade: (1) a alteração não foi registada corretamente no fornecedor DNS, (2) o cache negativo (NXDOMAIN) retém uma resposta antiga de "não existe", (3) o tipo de registo errado foi modificado, (4) a cadeia DNSSEC está quebrada (o registo DS não corresponde mais ao DNSKEY), (5) um relay DNS corporativo aplica cache agressivo. Diagnostique consultando diretamente o servidor autoritativo com dig captaindns.com A @ns1.captaindns.com para verificar se a alteração está de facto implementada na origem.

O que é o TTL DNS?

O TTL (Time To Live) é um campo numérico associado a cada registo DNS, expresso em segundos. Ele indica aos resolvedores recursivos por quanto tempo podem manter uma resposta em cache antes de precisar consultar novamente o servidor autoritativo. Por exemplo, um TTL de 3.600 significa que o resolvedor usará a resposta em cache por 1 hora. O TTL é definido pelo administrador da zona DNS, não pelo protocolo. Cada registo pode ter o seu próprio TTL.

É preciso esperar 24 a 48 horas após uma alteração DNS?

Não. Esse prazo só se impõe se o TTL do registo modificado for de 86.400 segundos (24 horas), que corresponde ao padrão histórico de alguns registrars. Com um TTL de 3.600 segundos (1 hora, padrão comum em 2026), o prazo máximo é de 1 hora. Preparando a migração (redução do TTL para 300 segundos 48 horas antes), a alteração fica visível em 5 minutos. A recomendação "24 a 48 horas" é um arredondamento de precaução datado dos anos 2000 que não reflete mais a realidade técnica atual.

Como limpar o cache DNS?

O cache DNS existe em vários níveis. Para limpar o cache da sua máquina: no Windows, execute ipconfig /flushdns no PowerShell; no macOS, execute sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder no Terminal; no Linux com systemd, execute sudo systemd-resolve --flush-caches. Para o Chrome, aceda a chrome://net-internals/#dns e clique em "Clear host cache". Para limpar o cache dos resolvedores públicos, use as interfaces do Google Public DNS e da Cloudflare 1.1.1.1. O cache do resolvedor do seu fornecedor de Internet não pode ser purgado manualmente.

Porque os resolvedores DNS dão resultados diferentes?

Três razões explicam esse comportamento. Primeiro, cada resolvedor armazenou o registo em cache em um momento diferente, então o TTL expira em instantes defasados. Segundo, os grandes resolvedores (Google, Cloudflare) usam redes anycast com centenas de servidores independentes; o servidor que atende Paris não possui o mesmo cache daquele que atende Tóquio. Terceiro, alguns domínios usam EDNS Client Subnet (ECS) para retornar endereços IP geolocalizados, o que produz respostas legitimamente diferentes conforme a localização do cliente.

Trocar de resolvedor DNS acelera a propagação?

Não, de forma fiável não. Trocar de resolvedor no seu computador (passar de 8.8.8.8 para 1.1.1.1, por exemplo) pode dar a impressão de que a alteração foi propagada, caso o novo resolvedor não tenha o registo antigo em cache. Mas isso não acelera nada para os outros utilizadores. O "prazo de propagação" está ligado ao TTL do cache de cada resolvedor, e não controla o cache do resolvedor usado pelos seus visitantes. O único método fiável para acelerar a propagação é reduzir o TTL antes da alteração.

Como verificar se a propagação DNS terminou?

Consulte pelo menos quatro resolvedores públicos principais com dig: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) e OpenDNS (208.67.222.222). Se todos retornam o novo valor, a propagação está completa para a grande maioria dos utilizadores. Para uma verificação exaustiva, use uma ferramenta de teste de propagação multi-resolvedores que consulta servidores distribuídos em vários continentes e exibe os resultados em tempo real. Enquanto pelo menos um resolvedor retornar o valor antigo, a propagação não terminou.

Glossário

TTL (Time To Live): duração em segundos durante a qual um resolvedor DNS pode manter um registo em cache antes de solicitá-lo novamente ao servidor autoritativo. Definido pelo administrador da zona.
Resolvedor recursivo: servidor DNS que recebe as consultas dos clientes e realiza a resolução completa consultando a hierarquia DNS (raiz, TLD, autoritativo). Exemplos: Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1).
Servidor autoritativo: servidor DNS que detém os registos originais de uma zona DNS. É a fonte da verdade para os registos de um domínio.
Cache DNS: memória temporária onde um resolvedor armazena as respostas DNS já obtidas. O cache reduz a carga nos servidores autoritativos e acelera as respostas.
Zona DNS: conjunto de registos DNS de um domínio e os seus subdomínios, alojado em um ou mais servidores autoritativos.
Registo NS (Name Server): registo que designa os servidores autoritativos de uma zona DNS. Publicado tanto na zona pai (delegação) quanto na própria zona.
Stub resolver: componente do sistema operacional que reencaminha as consultas DNS ao resolvedor recursivo configurado. Mantém um cache local mínimo.
SOA (Start of Authority): registo obrigatório em cada zona DNS que contém os metadados da zona (serial, refresh, retry, expire, TTL negativo).
NXDOMAIN: resposta DNS indicando que o nome de domínio solicitado não existe. Essa resposta é armazenada em cache conforme o TTL negativo definido no SOA.
Anycast: técnica de roteamento de rede na qual um mesmo endereço IP é anunciado a partir de vários locais geográficos. Os resolvedores públicos usam anycast para direcionar as consultas ao servidor mais próximo.

A ferramenta de teste de propagação CaptainDNS consulta resolvedores distribuídos em todos os continentes e exibe em tempo real o estado do cache para cada registo. Use-a para confirmar que uma alteração DNS está visível em todos os lugares antes de considerar a migração concluída.