Propagação de DNS: o que é e como reduzir o impacto

A propagação de DNS é o período em que alguns resolvedores continuam entregando o valor antigo de um registro depois de ele ser alterado no servidor de nomes autoritativo. Não é uma difusão: cada resolvedor guarda sua resposta em cache até o fim do TTL. O atraso vai de alguns minutos a 24 ou 48 horas em uma troca de servidores de nomes, conforme o TTL do registro antes da alteração e, no caso dos servidores de nomes, o TTL de delegação definido pelo registro do domínio de topo. Veja como isso funciona e como limitar o impacto.

Pontos principais

A alteração fica visível na hora no servidor autoritativo. O atraso vem apenas dos caches dos resolvedores, que mantêm o valor antigo até o TTL dele expirar.
Quem define quanto tempo o valor antigo permanece é o TTL em vigor antes da alteração, não o que você acabou de informar. Reduza-o com antecedência.
A troca de servidores de nomes é a mais lenta, porque depende do TTL de delegação do registro, que você não controla.
Os erros «este nome não existe» também ficam em cache: acessar um nome antes de criar o registro dele pode prolongar o erro.

O que a propagação de DNS não é: uma difusão

O termo engana. Nenhum servidor envia sua alteração aos outros. Quando você salva uma mudança no provedor de DNS, o servidor de nomes autoritativo da zona passa a entregar o novo valor imediatamente. O atraso está em outro lugar: nos caches.

Quando um dispositivo procura o endereço de um nome de domínio, a consulta passa por várias camadas, e cada uma pode guardar a resposta:

o navegador, cujo cache costuma durar cerca de um minuto e nem sempre respeita o TTL;
o sistema operacional, que mantém as respostas recentes;
o resolvedor recursivo, do provedor de internet ou público (por exemplo 8.8.8.8 do Google, 1.1.1.1 da Cloudflare), que percorre a hierarquia DNS e guarda o resultado.

Cada resolvedor aplica o TTL que o servidor autoritativo informou no momento em que ele guardou a resposta. Como nem todos consultaram ao mesmo tempo, as cópias expiram em momentos diferentes. Um registro com TTL de 3.600 segundos, guardado há 5 minutos, será renovado em 55 minutos. Daí os relatos contraditórios: um vê o site novo, outro o antigo, um terceiro um erro.

Quanto tempo dura a propagação de DNS

A duração depende do tipo de alteração. Um TTL de um dia (86.400 segundos) é comum, e os valores são maiores em registros que quase não mudam, como os servidores de nomes.

Tipo de alteração	Duração habitual	O que a determina
Alterar um registro existente (A, AAAA, CNAME, MX, TXT)	Até a duração do TTL antigo, de alguns minutos a 24 horas conforme a configuração	O TTL em vigor antes da alteração
Criar um registro que não existia	Variável, em geral no máximo algumas horas	O SOA da zona (TTL do SOA e campo MINIMUM)
Trocar os servidores de nomes no registrador	De algumas horas a 48 horas	O TTL de delegação do registro, muitas vezes de um a dois dias
Resolvedor com limites próprios	Pode ultrapassar o TTL informado	Um teto ou um piso configurado (86.400 s por padrão no Unbound, 604.800 s no BIND)

Os três fatores que decidem o atraso

O TTL de antes da alteração

Imagine um registro com TTL de 86.400 segundos que você ajusta hoje para 300. Um resolvedor que o guardou ontem mantém o valor antigo por até 24 horas, seja qual for o novo valor: o TTL de 300 segundos só vale depois que a cópia dele for renovada. Em um CNAME, cada nome da cadeia tem o próprio TTL, e o mais longo define o atraso total.

A delegação no registro

Ao trocar de servidores de nomes, a mudança é feita no registrador, que a repassa ao registro do domínio de topo. Os resolvedores que ainda conhecem a lista antiga de servidores de nomes continuam consultando-os até a delegação expirar. Esse TTL pertence ao registro: você não pode encurtá-lo.

Os resolvedores que não seguem o TTL ao pé da letra

Alguns resolvedores limitam ou elevam os TTLs, e os navegadores têm um cache próprio de curta duração. Não é possível garantir a mesma duração em todo lugar. O TTL é um limite teórico, não uma promessa de todos os caches.

A armadilha do cache negativo

A maioria dos guias fala do TTL dos registros e esquece as respostas negativas. Quando um resolvedor descobre que um nome não existe (resposta NXDOMAIN) ou que não há registro do tipo pedido, ele pode guardar essa ausência. A RFC 2308 define a duração do cache negativo como o menor entre dois valores: o TTL do SOA da zona e o campo MINIMUM dele. Ela considera razoáveis durações de uma a três horas e alerta que valores acima de um dia causam problemas.

O cenário típico: você testa novo.example.com antes de criar o registro, recebe um erro e depois cria o registro. Para o seu resolvedor, o nome «não existe» até o cache negativo terminar, mesmo que o registro esteja no ar há um minuto. Como evitar:

crie o registro antes de testar ou anunciar o nome;
se o seu provedor de DNS permitir ajustar o SOA, mantenha um campo MINIMUM moderado;
limpe o cache local antes de concluir que «não funciona»: a Microsoft informa que ipconfig /flushdns também descarta as entradas de cache negativas.

Método para limitar o impacto de uma migração

Anote o TTL atual de cada registro envolvido (veja os comandos abaixo). É ele que define o atraso.
Reduza o TTL para 300 segundos, com antecedência de pelo menos a duração do TTL antigo. Com 86.400 segundos, faça isso de 24 a 48 horas antes da troca. Confira o mínimo aceito pelo seu provedor.
Prepare o novo destino: site, servidor de e-mail ou CDN pronto para responder com o mesmo conteúdo do anterior. Os dois precisam funcionar durante a transição.
Troque o registro, uma alteração de cada vez para saber o que verificar.
Verifique primeiro o servidor autoritativo e depois os resolvedores públicos.
Mantenha o servidor antigo ativo pelo menos até passar o maior TTL antigo, e só então desligue-o.
Volte a subir o TTL (3.600 segundos ou mais) quando tudo estiver estável.

Em uma troca de servidores de nomes, recrie primeiro a zona completa no novo provedor (A, CNAME, MX, TXT com SPF e DKIM, e todo o resto), confira se ela responde corretamente e só então altere os servidores de nomes no registrador. Deixe a zona do provedor antigo no ar e idêntica por 48 horas: os resolvedores que ainda conhecem a delegação antiga continuam consultando-a.

Verificar o que cada resolvedor enxerga

O comando dig (macOS, Linux) ou nslookup (Windows) permite comparar o que respondem o servidor autoritativo e vários resolvedores públicos.

# Valor e TTL restante vistos por resolvedores públicos
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Servidores de nomes declarados para o domínio
dig +short NS example.com

# Valor entregue pelo servidor autoritativo (troque pelo seu servidor de nomes)
dig +noall +answer example.com A @ns1.provedor-dns.example

# Número de série do SOA, para comparar entre servidores de nomes
dig +short SOA example.com @ns1.provedor-dns.example
dig +short SOA example.com @ns2.provedor-dns.example

# Equivalente no Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

Na resposta de um resolvedor, o TTL exibido diminui de uma consulta para a outra: é o tempo que falta para a cópia expirar. Se um resolvedor devolve o valor antigo com um TTL que continua caindo enquanto o servidor autoritativo já devolve o novo, basta esperar.

Compare também o número de série do SOA entre os seus servidores de nomes. Se forem diferentes, algum servidor entrega dados desatualizados: o problema está no seu provedor de DNS, não na propagação. A página dns.google permite consultar um tipo de registro específico, inclusive o SOA, e o guia de solução de problemas do Google Public DNS detalha essa verificação.

Limpar os caches que você controla

Limpar o seu próprio cache não muda nada para os outros visitantes, mas mostra o que você realmente enxerga.

# Windows (prompt de comando)
ipconfig /flushdns

# macOS recente
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux com systemd-resolved
resolvectl flush-caches

A Microsoft descreve /flushdns e /displaydns na página do comando ipconfig. Depois feche o navegador por completo, pois ele guarda uma memória própria de curta duração.

Dois resolvedores públicos também oferecem uma limpeza, útil depois de uma troca de servidores de nomes ou para quem os usa: a ferramenta Flush Cache do Google Public DNS (o Google recomenda limpar tanto o domínio registrado quanto o nome exato que devolve uma resposta desatualizada) e a limpeza de cache do 1.1.1.1 da Cloudflare, em que se escolhe o domínio e o tipo de registro. Os resolvedores dos provedores de internet não podem ser limpos: é preciso esperar as cópias expirarem.

Erros frequentes

Reduzir o TTL na hora da troca. Já é tarde: os resolvedores mantêm a cópia feita com o TTL antigo.
Testar o nome antes de criar o registro. O cache negativo pode prolongar o erro.
Trocar os servidores de nomes antes de recriar toda a zona. Registros de e-mail ou de subdomínios esquecidos deixam de funcionar para os resolvedores que já consultam o novo provedor.
Desligar o servidor antigo cedo demais. Os visitantes cujo cache não expirou caem em um servidor que não responde mais.
Concluir que a propagação acabou a partir do seu computador. O seu cache local não representa os demais resolvedores.
Deixar um TTL muito baixo de forma permanente. Isso multiplica as consultas aos seus servidores de nomes. Volte a subi-lo depois da migração.

Perguntas frequentes

Quanto tempo dura a propagação de DNS?

Ao alterar um registro, no máximo a duração do TTL antigo: uma hora com TTL de 3.600 segundos, 24 horas com 86.400. Em uma troca de servidores de nomes, de algumas horas a 48 horas. A maioria dos resolvedores se atualiza bem antes do prazo máximo. Sobram alguns caches atrasados.

É possível acelerar a propagação de DNS?

Não em toda a internet: não dá para forçar os caches dos outros. Dá para reduzir o TTL antes da alteração, limpar os resolvedores públicos do Google e da Cloudflare e esvaziar os seus próprios caches. Os resolvedores dos provedores de internet não podem ser limpos.

Qual TTL escolher antes de uma migração?

Um valor curto, como 300 segundos (5 minutos), aplicado pelo menos durante o TTL antigo antes da troca. Com a migração estável, volte a subir para 3.600 segundos ou mais: um TTL muito baixo e permanente multiplica as consultas. Confira o mínimo aceito pelo seu provedor de DNS.

Por que meu colega vê o site novo e eu não?

Vocês passam por resolvedores diferentes, que guardaram a resposta em momentos diferentes. Consulte o mesmo resolvedor público nos dois computadores para comparar e limpe o cache local do computador que ainda vê a versão antiga.

O que acontece com meus e-mails durante a propagação?

Uma alteração de registro MX segue as mesmas regras: durante o atraso, alguns remetentes ainda escrevem para o servidor de e-mail antigo. Mantenha-o ativo até o fim da transição. Se um servidor estiver indisponível, os servidores de envio costumam guardar as mensagens e tentar de novo por vários dias.

Preciso limpar o cache do computador?

Sim, para conferir o que você enxerga, mas isso não muda nada para os outros visitantes. Use o comando do seu sistema e feche o navegador por completo. Se o valor continuar antigo, a cópia está no resolvedor do seu provedor de internet.

Por que as ferramentas online de verificação mostram resultados diferentes?

Cada uma consulta resolvedores de países diferentes, que guardaram a resposta em momentos diferentes. Um resultado misto é normal enquanto o TTL não tiver expirado em todos os lugares. Se os próprios servidores de nomes autoritativos respondem de forma diferente, compare os números de série do SOA: o problema está então na zona, não na propagação.