Mudou os nameservers, ou mudou um registo, e continua a ver o sítio antigo. Isto quase nunca é uma avaria: é uma resposta guardada em algum lado. Este artigo mostra-lhe onde ela está guardada, porque é que cada sítio mente de maneira diferente, e como se fura cada camada.
|
O TTL que manda é o ANTIGO. Toda a gente muda o registo e a seguir baixa o TTL para cinco minutos, a pensar que assim vai mais depressa. Não vai. Quem guardou a resposta velha guardou-a com o TTL velho, e só volta a perguntar quando esse tempo acabar. O TTL novo só começa a valer na próxima alteração. Baixar o TTL serve, mas tem de se fazer antes de mudar, com a antecedência do TTL que lá está hoje.
|
Os quatro sítios, e a mentira de cada um
| Onde |
Porque mente |
Como se fura |
| 1. O navegador |
Guarda a página, as imagens e, em alguns casos, a própria resposta de DNS. E se o site já esteve em https, o navegador pode recusar-se a ir por http mesmo que você escreva assim. |
Janela privada, outro navegador, outro aparelho. Recarregar forçando, e limpar o histórico do último período. Nunca use só o seu navegador como prova. |
| 2. A cache do computador |
O sistema operativo guarda respostas por conta própria, e nem sempre respeita o TTL à risca. É a camada que faz o site abrir no telemóvel e não abrir no portátil. |
No Windows: ipconfig /flushdns. No Linux com systemd: resolvectl flush-caches. No macOS: sudo dscacheutil -flushcache seguido de sudo killall -HUP mDNSResponder. |
| 3. O resolvedor do fornecedor de Internet |
É este que manda no tempo real de espera. Ele guardou a resposta antiga e só vai voltar a perguntar quando o TTL antigo acabar. Não há botão nenhum que o obrigue. |
Esperar, ou perguntar a outro. Um telemóvel em dados móveis usa outro resolvedor e serve de segunda opinião. Por comando, pode perguntar a um resolvedor público qualquer, por exemplo dig @1.1.1.1 A yourcompany.com ou dig @8.8.8.8 A yourcompany.com. |
| 4. A zona autoritativa |
Não mente. É a fonte. Se aqui estiver certo, a alteração está feita e o resto é tempo. Se aqui estiver errado, não adianta esperar: não foi gravada, ou foi gravada no sítio errado. |
Pergunte-lhe directamente: dig @dns1.mozout.com A yourcompany.com. Troque o registo por MX ou TXT conforme o que mudou. |
|
Há ainda uma quinta camada, e é a mais lenta de todas: a delegação guardada no registo da extensão, ou seja, a lista de nameservers. Tem TTL próprio, costuma ser mais longo do que o dos registos, e é por isso que trocar nameservers demora mais a ver-se do que trocar um registo A. Se só mudou um registo dentro da zona, esta camada nem entra na conta.
|
A ordem certa de confirmar: de dentro para fora
Faça por esta ordem. Assim que um passo falhar, pare: encontrou o problema, e os passos seguintes só lhe dariam informação errada.
| 1 |
Pergunte à fonte. dig @dns1.mozout.com A yourcompany.com. Está certo? Então a alteração existe e só falta tempo. Está errado? A alteração não foi gravada onde devia; volte ao painel.
|
|
| 2 |
Pergunte pela delegação. dig NS yourcompany.com. Os nameservers que aparecem são os que mandam de facto. Se ainda forem os antigos, é a delegação que está por mudar, e o resto não interessa.
|
|
| 3 |
Pergunte a um resolvedor de fora. dig @1.1.1.1 A yourcompany.com. Se aqui já estiver certo e no seu escritório não, o problema é local e resolve-se nos dois passos seguintes.
|
|
| 4 |
Limpe a cache do seu computador, com o comando da tabela para o seu sistema.
|
|
| 5 |
Abra numa janela privada, ou noutro aparelho, ou em dados móveis. Se agora aparece bem, acabou: o que faltava era a sua própria máquina.
|
|
Quanto tempo se espera
Não damos um número, porque não há um: o tempo é o TTL que a resposta antiga declarava, e esse foi decidido por quem tinha a zona antes. Pode ser curto, pode ser longo. O artigo quanto tempo demora a propagação explica a mecânica, e como verificar o DNS do domínio dá as consultas passo a passo.
|
A única coisa que encurta mesmo a espera é baixar o TTL do registo antes de o mudar, e esperar o tempo do TTL antigo antes de fazer a alteração a sério. Numa mudança de servidor planeada, é isto que separa uma janela de minutos de uma janela de dias. Podemos preparar isto consigo.
|
Quando já não é propagação
Ao fim do TTL antigo, se continuar a ver o velho em toda a parte, deixe de esperar. Nesse ponto, as causas são outras.
| Sintoma |
O que é, quase sempre |
| A fonte responde o valor antigo |
A alteração não foi gravada, ou foi gravada numa zona que já ninguém lê (o caso clássico: editar no registador depois de os nameservers já serem nossos). |
| O site abre mas dá aviso de segurança |
Não é DNS: é o certificado, que só se emite depois de o domínio apontar para cá. Veja a validação do domínio. |
| Aparece uma lista de ficheiros em vez do site |
O DNS está certo e o que falta é conteúdo. Veja ver o site antes de o domínio apontar. |
| Aparece a página do antigo fornecedor |
Sobrou um registo a apontar para lá, ou o estacionamento do registador continua ligado. |
| O site vê-se e o e-mail deixou de chegar |
Os MX foram atrás dos nameservers. É urgente. Veja porque o e-mail não envia ou não recebe. |
| O domínio não resolve para ninguém, nem na fonte |
Pode ser DNSSEC que ficou activo no registador depois de a zona mudar, ou o domínio pode ter expirado. Veja domínio expirado. |
E se o site está mesmo em baixo e não é nada disto, a lista de verificações está em o seu site está fora do ar.
|
Diga-nos o domínio e o que mudou. Consultamos as quatro camadas do nosso lado e dizemos-lhe se falta esperar ou se falta corrigir.
Abrir um pedido de suporte
|
PRODUTO RECOMENDADO Registe o seu domínio .com Garanta o nome da sua empresa antes que outro o registe. a partir de 15,30 €/ano Pesquisar domínio |
Angola
Brasil
Kenya
Moçambique
Nigeria
Portugal
South Africa
United Kingdom
United States
International
