"Propagação": porque é que uns já veem e outros ainda não

Módulo 6: Tempo, cache e transferência de domínio · Tempo de leitura: 8 minutos

Objetivo de aprendizagem: Após esta lição, conseguirá explicar porque é que uma alteração de DNS não é visível em todo o lado ao mesmo tempo, estimar quanto tempo demora e resolver o problema caso só você ainda veja a situação antiga.

Conceitos-chave: "propagação", cache, cache negativa (NXDOMAIN), mínimo do SOA, TTL de delegação, alteração de servidor de nomes, limpar a cache

Um mal-entendido numa só palavra

Alterou um registo. O seu colega já vê o novo website, mas você continua a ver o antigo. Na internet lê-se então: "espere, o DNS ainda tem de propagar." A palavra propagação (difusão) dá a ideia de que a sua alteração se espalha como uma onda pela internet, de servidor para servidor.

Não é assim que funciona. A sua alteração fica imediatamente registada nos servidores de nomes autoritativos do seu domínio (ou dentro de alguns minutos, se o seu fornecedor de DNS sincronizar vários servidores de nomes). Não há nada a ser enviado. O que vê é o esgotar das caches: cada resolver (resolver) dá a resposta antiga até a TTL na sua cache terminar (lição 6.1). Como cada resolver começou a contar num momento diferente, uns veem a alteração mais cedo do que outros.

A "propagação" é, portanto, na realidade: esperar até que todas as caches se esvaziem. Esta compreensão ajuda, porque agora sabe exatamente pelo que está a esperar e durante quanto tempo, no máximo.

Quanto tempo demora?

Isso depende do que está a alterar.

Registos existentes

Aqui é simples: a TTL antiga é o máximo. Se o registo tinha TTL 3600, todos veem a nova resposta até, no máximo, uma hora após a sua alteração. Se, passada mais de uma hora, alguém ainda vir o antigo, o problema está noutro sítio (ver mais à frente).

Registos novos e a cache negativa

Um registo novo funciona muitas vezes de imediato, exceto se alguém já tiver consultado o nome quando este ainda não existia. Nesse caso, o resolver recebeu a resposta NXDOMAIN ("este nome não existe") ou "este nome existe, mas não tem registo deste tipo". Esse "não" também é memorizado. A isto chama-se a cache negativa.

Durante quanto tempo um "não" é guardado não consta num registo que não existe. Vem do registo SOA da zona: segundo a RFC 2308, é o menor de dois números, a TTL do próprio registo SOA e o último campo do registo SOA (o "mínimo"). Um exemplo:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; número de série
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; mínimo

Aqui, um "não" é memorizado durante, no máximo, 300 segundos (o menor entre 3600 e 300). Noutras zonas, pode ser uma hora ou mais.

Daí a regra de ouro: não abra um novo subdomínio no seu navegador antes de o ter criado. O seu computador e o seu resolver memorizam então que ele não existe, e é só você quem tem de esperar.

Alterar servidores de nomes

Numa alteração de servidores de nomes, espera-se por outra coisa: os registos NS na registry da sua extensão. Esses registos indicam aos resolvers onde estão os servidores de nomes do seu domínio (lição 2.1), e também estes são memorizados. Cada registry escolhe a sua própria TTL para isso. Medido em novembro de 2026:

Acresce que uma registry por vezes não publica a sua alteração de imediato, e que os servidores de nomes do seu fornecedor anterior continuam, entretanto, muitas vezes a responder com a zona antiga. Conte, por isso, com algumas horas numa mudança de servidores de nomes e, no caso do .com, até dois dias no máximo. Certifique-se, portanto, de que ambos os fornecedores têm os mesmos registos corretos durante a mudança (lição 6.3).

É só você quem ainda vê o antigo?

Um verificador online já mostra a nova resposta em quase todos os resolvers, mas você não? Então a resposta antiga está algures perto de si. Percorra estes passos, do mais rápido ao mais aprofundado:

1. Janela privada ou outro navegador. O seu navegador guarda respostas de DNS e páginas.
2. Telemóvel via 4G ou 5G, com o wifi desligado. Assim utiliza o resolver do seu operador móvel em vez do da sua rede doméstica.

3. Limpar a cache do seu computador.

   • Windows (Linha de comandos): ipconfig /flushdns
   • macOS (Terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux com systemd-resolved: resolvectl flush-caches
4. Reiniciar o router. Muitos routers funcionam como um pequeno resolver com cache própria.
5. Verificar o ficheiro hosts. Testou anteriormente um novo servidor colocando o endereço no seu ficheiro hosts (C:\Windows\System32\drivers\etc\hosts ou /etc/hosts)? Essa linha tem prioridade sobre o DNS. Remova-a. Isto é frequentemente esquecido.
6. Verificar diretamente na fonte. Consulte o registo junto do servidor de nomes autoritativo (dig A example.com @ns1.hosting.example). Se aí ainda constar a resposta antiga, a alteração não foi guardada corretamente ou foi feita no local errado.

Depois do tempo de espera, continua sem nada?

Se a TTL já expirou há muito e também as ferramentas online mostram a resposta antiga, esperar não tem utilidade. Nesse caso, há outra coisa a acontecer. As três causas mais frequentes:

• Alterado no local errado. O seu domínio utiliza os servidores de nomes de outro fornecedor (por exemplo, Cloudflare ou um construtor de websites), e você alterou os registos junto do seu fornecedor de alojamento. Verifique quais são os servidores de nomes do seu domínio (lição 2.1) e altere aí.
• Erro de digitação ou ponto final em falta. mail.example.com sem ponto final torna-se, em muitos painéis, mail.example.com.example.com (lição 2.2).
• Os servidores de nomes não estão de acordo entre si. Um domínio tem pelo menos dois servidores de nomes. Se estes não sincronizarem bem, um dá a resposta nova e o outro a antiga. Compare o número de série do SOA em cada servidor de nomes: deve ser igual.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

Na prática: como se apresenta num painel

Quer ver o que os resolvers em diferentes pontos do mundo respondem? Utilize um verificador de DNS online que consulte um resolver por país (por exemplo, dnschecker.org). No painel de exemplo O meu WebOké, o cartão Domínio / E-mail saúde verifica os servidores de nomes e os registos do seu domínio junto dos servidores de nomes autoritativos, e o diagnóstico de DNS compara os números de série dos servidores de nomes. Outros fornecedores têm muitas vezes uma verificação semelhante no seu painel; se não tiverem, o dig e as ferramentas online da lição 8.3 dão o mesmo resultado.

Resumo

• Não há nada a ser "difundido": espera-se que as caches expirem.
• Um registo alterado é visível em todo o lado, no máximo, após a TTL antiga; um registo novo normalmente é visível de imediato, exceto se alguém já tiver consultado o nome antes (cache negativa, determinada pelo registo SOA).
• Uma mudança de servidores de nomes depende da TTL na registry: no .nl, uma hora; no .com, dois dias.
• Só você vê o antigo? Janela privada, 4G, limpar a cache, reiniciar o router e verificar o ficheiro hosts.
• Continua antigo junto do servidor de nomes autoritativo? Então esperar não serve de nada: procure o erro.

Quiz

Exercício

Exercício Z6.2: TTL de delegação e cache negativa. Duas perguntas, ambas a responder com dig ou uma ferramenta dig online:

1. Durante quantos segundos memorizam os resolvers, segundo a registry do .com, os servidores de nomes de google.com? Consulte um servidor .com: dig NS google.com @a.gtld-servers.net e veja a TTL na secção AUTHORITY.
2. Durante quantos segundos memoriza um resolver que um nome sob sidn.nl não existe? Consulte o registo SOA de sidn.nl (a página da SIDN, a registry do .nl na Holanda) junto de ns1.sidn.nl e aplique a regra desta lição (o menor entre a TTL do SOA e o mínimo do SOA).

Para saber mais

Os passos nestes artigos referem-se aos painéis da WebOké; noutros painéis o funcionamento é semelhante.

• Quanto tempo demora uma alteração de nameserver ou DNS, e o que fazer se não a conseguir ver?
• O seu site ou e-mail não funciona após uma migração ou alteração de DNS: verifique o seu domínio
• Manual DirectAdmin 5.11: Quando é que uma alteração tem efeito? Tempo de espera e TTL
• Criar um subdomínio e o que fazer se não funcionar
• Como posso testar o meu domínio antes de ser transferido? (localhost)
• Manual do WebOké 5.17: Saúde do domínio e e-mail: verificar e resolver