Propagação de DNS: por que demora e como verificar

Você trocou o IP do domínio, salvou, e o site continua mostrando a versão velha (ou nada). Um colega abre normalmente, você não. A explicação popular é "o DNS está propagando", como se a mudança viajasse de servidor em servidor. Na prática, nada viaja: o que existe é uma coleção de caches, cada um com um cronômetro.

Entender isso muda o que você faz. Em vez de esperar sem saber o quê, você descobre qual cache ainda guarda o valor antigo, quanto falta para ele expirar e se vale limpá-lo à mão.

O que é, de fato, a propagação de DNS?#

Quando você altera um registro no painel do seu provedor de DNS, a mudança vale na hora no servidor autoritativo, o que guarda a verdade sobre o domínio. O resto da internet só descobre quando precisa perguntar de novo.

Ninguém avisa os outros servidores. Resolvedores (o do seu provedor de internet, 8.8.8.8, 1.1.1.1) guardam cada resposta em cache por um tempo e só voltam ao autoritativo quando esse tempo acaba. "Propagação" é o nome informal para a janela entre a mudança e o último cache relevante expirar.

Por isso o resultado varia por pessoa. Duas pessoas em redes diferentes consultam resolvedores diferentes, que buscaram o registro em momentos diferentes.

O que é o TTL e por que ele manda no prazo?#

TTL (time to live) é um número de segundos que vem junto de cada registro e diz por quanto tempo um resolvedor pode reutilizar a resposta sem perguntar de novo. A documentação da Cloudflare resume a troca: TTL longo gera mais acertos de cache e consultas mais rápidas, mas atrasa a propagação de mudanças.

Exemplo: o registro A de exemplo.com tem TTL 3600. Um resolvedor consultou às 10h00. Se você mudar o IP às 10h05, esse resolvedor continua entregando o IP antigo até as 11h00. Outro, que consultou às 10h50, só atualiza às 11h50. O pior caso é, portanto, o TTL antigo inteiro contado a partir da mudança.

Duas consequências práticas:

• O TTL que vale é o do registro antigo. Baixar o TTL depois de trocar o IP não ajuda quem já guardou a resposta.
• 300 segundos (5 minutos) é um padrão comum. Os provedores costumam impor um mínimo, que pode variar por plano; confira na documentação do seu.

Em quais lugares o registro antigo fica guardado?#

Uma consulta passa por várias camadas, e qualquer uma pode segurar o valor velho:

1. Navegador. Mantém um cache de DNS próprio por alguns instantes.
2. Sistema operacional. Windows, macOS e muitas distribuições Linux têm um cache local.
3. Roteador de casa ou da empresa. Muitos fazem de proxy DNS e guardam respostas.
4. Resolvedor recursivo. O do provedor de internet, ou público como 8.8.8.8 (Google) e 1.1.1.1 (Cloudflare). É o cache mais importante, compartilhado por milhares de usuários.
5. Servidores autoritativos. Não são cache: respondem com a verdade atual.

Há um caso mais lento: a troca de nameservers (os servidores NS que o registrador informa à zona pai, como .com). Essa delegação tem TTL próprio, definido por quem opera o TLD, e costuma ser bem maior que o de um registro A. Em trocas de provedor de DNS, reserve horas, em alguns casos até dois dias, e mantenha os registros idênticos nos dois provedores durante a transição.

E se o nome ainda não existia (cache negativo)?#

Se alguém consultou o nome antes de você criar o registro, o resolvedor pode ter guardado a resposta "não existe" (NXDOMAIN). Isso se chama cache negativo e está na RFC 2308: o tempo é o menor valor entre o TTL do registro SOA da zona e o campo MINIMUM desse mesmo SOA.

É por isso que, às vezes, um nome recém-criado continua dando erro por alguns minutos ou horas, mesmo com o registro já correto no autoritativo. Se você viu esse erro no navegador, veja DNS_PROBE_FINISHED_NXDOMAIN.

Como verificar o estado da propagação?#

O método confiável é perguntar a cada camada e comparar. Use dig (Linux, macOS, Windows com BIND ou WSL) ou nslookup (já vem no Windows).

1. Descubra o autoritativo e consulte direto. Ele é a referência:

dig NS exemplo.com +short
ns1.provedor-dns.example.
ns2.provedor-dns.example.

dig @ns1.provedor-dns.example exemplo.com A +short
203.0.113.10

Se aqui já aparece o valor novo (203.0.113.10 no exemplo), sua configuração está certa e o resto é cache. Se aparece o antigo, a mudança não foi salva, ou você editou o DNS em um provedor que não é o dos nameservers atuais (a causa mais comum de "nunca propaga").

2. Consulte resolvedores públicos. Cada um tem seu cache:

dig @8.8.8.8 exemplo.com A
dig @1.1.1.1 exemplo.com A

Na seção ANSWER, o número entre o nome e o tipo é o TTL restante daquele cache. Rode duas vezes: o valor desce. Quando chega a zero, o resolvedor busca o registro novo.

exemplo.com.    1742    IN    A    198.51.100.7

Aqui, esse resolvedor ainda entrega o IP antigo por mais 1742 segundos (cerca de 29 minutos).

3. No Windows sem dig:

nslookup exemplo.com 8.8.8.8
nslookup -type=NS exemplo.com

4. Veja o caminho completo. dig +trace exemplo.com parte dos servidores raiz e mostra cada delegação até o autoritativo, ignorando caches do meio.

Sites de "checagem global de DNS" fazem essa mesma comparação em vários países de uma vez. São úteis para ter uma visão ampla, mas o resultado vale só para os resolvedores que eles consultam, não para o provedor de internet de uma pessoa específica.

Como acelerar ou contornar quando está demorando?#

Limpe o cache local. Isso resolve o seu computador, não o mundo:

No Windows:

ipconfig /flushdns

No macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

No Linux com systemd-resolved:

sudo resolvectl flush-caches

Reinicie o navegador depois, ou teste em uma janela anônima. O ipconfig /flushdns descarta inclusive as entradas de cache negativo, segundo a documentação da Microsoft.

Peça ao resolvedor público que esqueça o nome. O Google tem uma ferramenta de Flush Cache para o Google Public DNS, e a Cloudflare tem a Purge Cache para o 1.1.1.1. Você informa o domínio (na Cloudflare, também o tipo de registro). Isso afeta só aquele resolvedor, mas ajuda muito quem usa 8.8.8.8 ou 1.1.1.1.

Teste por outro caminho. Dados móveis do celular usam outro resolvedor, e uma VPN também. Se funciona por lá, o seu cache é o culpado.

Contorne sem esperar. Para testar a hospedagem antes do DNS valer, force o IP no seu computador só naquela requisição:

curl --resolve exemplo.com:443:203.0.113.10 https://exemplo.com/

Como planejar uma mudança sem ficar fora do ar?#

O truque é agir antes, porque o que manda é o TTL antigo:

1. Com antecedência igual ao TTL atual (um dia, se ele for 86400), reduza o TTL do registro para 300 segundos.
2. Espere o TTL antigo passar, para que todos os caches já estejam no regime curto.
3. Faça a troca do valor do registro.
4. Confirme com dig no autoritativo e em 8.8.8.8 e 1.1.1.1.
5. Depois de tudo estável, suba o TTL de volta, para reduzir consultas.

Se possível, deixe o servidor antigo no ar, respondendo normalmente, até o fim da janela. Assim, quem ainda enxerga o IP velho encontra o site funcionando.

Para mais sobre os tipos de registro que você vai editar, veja o que são registros DNS e como apontar um domínio para sua hospedagem.

Como fazer isso na Square Cloud#

Domínio personalizado na Square Cloud está disponível a partir do plano Standard. O painel mostra os registros DNS que você precisa criar, e você os cria no seu registrador. O domínio continua registrado em seu nome no registrador, e a Square Cloud não é registrador nem provedor de DNS: o TTL e o cache que você viu acima são os do seu provedor de DNS.

A validação aparece em tempo real: depois que você cria os registros, o painel indica quando os encontrou, então você não precisa ficar rodando dig às cegas, embora o comando continue sendo a melhor forma de enxergar o que cada resolvedor responde. O TLS é emitido automaticamente, e o painel também permite fazer purge de cache.

Enquanto o domínio não é validado, a aplicação web continua acessível pelo subdomínio *.squareweb.app com HTTPS, disponível em todo plano. Confira como configurar em domínios na Square Cloud.